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(57) Abstract: The invention relates to a transmission 
of data in a mobile radio network, in particular a trans- 
mission of text and/or image data, with or without sound 
in multimedia messages (MM). During said transmis- 
sion, at least one identification signal for a data record 
or several records is allocated to the data and said identi- 
fication signa](s) is/aie transmitted to the receiver of the 
data. 

(57) Zusammenfassong: Bei einer DatenGbertragung 
in dnem Mobilfunknetz, insbesondere einer 
Obertiaguqg von Text- und/oder Bilddaten mit und 
ohne Ton inneriialb Multimedia messages (MM), wird 
den Daten znmindest ein Identifikationssignal fur 
einen Datensatz oder mehrere Datensatze zngeardnet 
und dieses oder diese Identifikationssignal(e) an den 
Empfanger der Daten iibeitragen. 
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Beschreibung 

VBRFAHREN OND NOBILTBLEKQMMDNIKATIONSGERAT ZUR DATSNdBBRTRAGDNG IN BINEN 
MOBXLFONKNETZ 

5 Die Erfindung betrifft ein Verfahren zur Datentibertragung in 
einem Mobilfunknetz nach dem Oberbegrif f des Anspruchs 1 so- 
wie ein mobiles Telekommunikationsgerat nach dem Oberbegriff 
des Anspruchs 26, ein Computerprogrammerzeugnis nach Anspruch 
30, sowie ein Funkkomaunikationssystem nach Anspruch 32. ' ' 

10 

Bisherige Mobilfunknetze, wie etwa das nach dem GSM-Standard 
arbeitende Netz, eroffnen noch recht eingeschrankte M5glich- 
keiten zur tJbertragung von Textdaten. So konnen etwa bis zu 
160 Zeichen umfassende Kurznachrichten ubertragen werden. 
15 Diese Einrichtung wird als SMS (Short Message Service) be- 
zeichnet. Fur die Kosten des Versands derartiger Textnach- 
richten hat der Da tenver sender aufzukommen, 

Zuktlnftig soli auch eine tJbertragung von Multimediadaten, 
20 insbesondere stehenden oder bewegten Bildern mit oder ohne 
Ton, moglich sein. Es ist mit einer erheblichen Ausweitung 
der Datenubertragungsmengen und der Datentypen innerhalb sol- 
cher t&ertragimgen zu rechnen, was mit erhShter ttoertragungs- 
zeit und einer Kostensteigerung einhergeht. 

25 

Der Erfindung liegt das Problem zugrunde, die Kontrolle der 
Datentibertragung ftir Tellnehmer eines Mobilfunknetzes zu ver- 
einfachen. 

30 Die Erfindung lost dieses Problem durch ein Verfahren mit den 
Merkmalen des Anspruchs 1, sowie durch ein Mobiltelekommuni- 
kationsgerat mit den Merkmalen des Anspruchs 26, ein Compu- 
terprogrammerzeugnis mit den Merkmalen des Anspruchs 30, so- 
wie durch ein Funkkommunikationssystem nach Anspruch 32. Hin- 
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sichtlich vorteilhafter Ausgestaltungen wird auf die Ansprti- 
che 2 bis 25, 27 bis 29 und 31 verwiesen. 

Mit dem er f iiidungs gema B en Verfahren ist eine Information an 
den DatenempfcLnger tlber Charakteristika der zum Empfang be- 
5 reitstehenden Daten moglich/ was diesem die Kontrolle hier- 
Ober erleichtert. 

Bei Vorabzusendung des oder der Charakteristika der zu liber- 
sendenden Daten angebenden Identif ikationssignal (e) ist die 

10 Kontrolle bereits vor Empfang der eigentlichen Daten ermGg- 
licht/ wobei besonders vorteilhaft dem Empf^nger anhand der 
so erhaltenen Information eine Ausweihlmoglichkeit eroffnet 
ist, ob er die bereitstehenden Daten jetzt oder spSter oder 
gar nicht empfangen m5chte. Wenn auch die Wahlmdglichkeit ei-* 

15 nes teilweisen Empfangs einer Multimedia message (MM) vorge- 
sehen ist/ kann der Empfanger beispielsweise nur ftir ihn 
wichtige Kurzinformationen, die eine kurze tJbertragungszeit 
benotigen, herunterladen und eventuell zugehGrige speicherin- 
tensive Bildbestandteile oder alinliches spSter oder gar nicht 

20 heriinter laden. 

Wenn das daftir eingesetzte Identifiziejrungssignal Information 
tiber die GrSBe eines zu empfangenden Datensatzes enthait/ 
kann der Empfanger daran ermitteln, wieviel Zeit er ftir die 
25 tibertragung und/oder das Studium der Daten rechnen mufi und ob 
er diese Zeit jetzt oder zu elnem spateren Zeitpunkt oder gar 
nicht aufbringen will. 

Wenn das Identifizierungssignal Information tiber den Namen 
30 eines Datensatzes enthait, kann der Empfanger daran ermit- 

teln, aus welchem Themenkomplex die Daten stammen. Auch daran 
kann er vorteilhaft auswahlen, ob er diesen oder diese Daten- 
satz Oder Datensatze jetzt oder zu einem spateren Zeitpunkt 
Oder gar nicht empfangen will. 



35 
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3 

Besonders vorteilhaft kann im Identifikationssignal auch In- 
formation tlber den Datentyp gegeben seln, so daB der Empfan- 
ger weiB, ob es sich beispielsweise um Bilddaten^ Textdaten 
und/oder Musikdaten handelt. 

5 

Kontrolle \ind Transparenz sind damit entscheidend verbessert. 



Weitere Vorteile und Merkmale der Erfindung ergeben sich aus 
' in den Zeichnungen neu dargestellten und nachfolgend be- 
10 schriebenen AusfUhrungsbeispielen des Gegenstandes der Erfin- 
dung. 



Es zeigen: 



15 Fig* 1 eine schematische Abbildung von einer Datentibertra- 
gung zugeordneten Sendungen gemaB dem WAP-Standard 
(Wireless application protocoll) zwischen der Ebene 
des Versenders und der des Providers einerseits und 
der Ebene des Providers und der des Empfangers an- 

20 dererseits. 

Fig. 2 die Header-Felder einer nach dem in Fig. 1 gezeig- 
ten WAP-Standard gesendeten Nachricht M-Send^req, 
wobei die erfindungsgem^ neu eingeftigten Header- 
25 Felder grau unterlegt sind. 

Fig. 3 eine Spezifizierung des Typs der in Fig. 2 gezeig- 
ten und in den grau unterlegten Feldem abgelegten 
Infoirmationen sowie des zusatzlich im Statusb.ericht 
30 auftretenden Feldes tiber den Erhalt der verssindten 

Daten, 

Fig. 4 eine Darstellung der Zuweisung der Header-Felder 
aus Fig. 2 zu den binaren Codes, wobei die erfin- 
dungsgemafi neu eingeftlgten Header-Felder grau un- 
35 terlegt sind. 
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Fig. 5 eine ahnliche Darstellung wie Fig. 2 der nach dem 
in Fig. 1 gezeigten WAP-Standard gesendeten Nach- 
richt M-Notification.ind (MNI)^ 

Fig. 6 eine ahnliche Darstellung wie Fig. 2 der nach dem 
in Fig. 1 gezeigten WAP-Standard gesendeten Nach- 
richt M-Retrieve . conf (MRC) , 

eine ahnliche Darstellung wie Fig. 2 der nach dem 
in Fig. 1 gezeigten WAP-Standard gesendeten Nach- 
richt M-Acknowledge . ind (MAI)^ 

eine ahnliche Darstellung wie Fig. 2 der nach dem 
in Fig. 1 gezeigten WAP-Standard gesendeten Nach- 
richt M-Deli very. ind. (MDI), 



Fig. 7 



Fig. 8 



Figuren 
9-17 und 

23-25 jeweils exemplarisch den. Inhalt verschiedener In- 
formationssignale ftir die tJbertragung von Multime- 
dlanachrichten zwischen mehreren Komponenten eines 
FunkkommunikationssystexDs nach dem erfindungsgemSL- 
Ben Verfahren, 

Figur 18 das Encoding eines einzigen Header-Feld-Namens, 

Figur 19 Eiicoding (Kodierung) der neuen Parameternamen und 
Parameterwerte im einzigen Headerfeld nach Figur 9, 

Figur 20 Zuweisung binarer Codes zu den Feldnamen der Para- 
meter im einzigen Headerfeld nach Figur 9, 



Figur 21A, 21B das einzige Header-Felder einer Multimedia 
Service (MMS) Sendeanfrage (in WAP Message M- 
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Send, req; ) , und 

Figur 22 das zur Sendeanfrage MSreq nach Figur 12A, 12B zuge- 
harige Header-Felder der MMS Empfangerbenachrichti- 
5 gung (M-Nind; in WAP Message M-Notification.ind ;) 

Elemente mit gleicher Funktion und Wirkungsweise sind in den 
Figuren 1 mit 13 jeweils mit denselben Bezugszeichen verse- 
hen. " 

10 

Im AusfUhrungsbei spiel ist die Anwendung der Erfindung auf 
ein Datentibertragungsschema 1 ftlr den WAP-Stcmdard, wie es in 
der Obertragiing von insbesondere Bilddaten und foiniiatierten 
Textdaten im UMTS-Standard (Universal mobile telecommunicati- 
15 on standard) Verwendung finden wird, beschrieben. Es versteht 
sich, daB die Erfindung auch auf andere Standards tibertragbar 
. ist. 

Im UMTS-Standard ist vorgesehen, zusatzlich zum bisherigen 
20 SMS einen sogenannten MMS (Multimedia Messaging Service) ftir 
die tJbertragung von Nachrichten, auch als Multimedia messages 
(MMs) bezeichnet, vorzusehen. Damit konnen auch formatierte 
Texte und Bilder mit und ohne Ton tlbertragen werden. Die im 
SMS vorhandene BeschrSnkung auf eine NachrichtenlSLnge von 160 
25 Zeichen entfSllt. Eine t)bertrag\ing von Audio- und Videonach- 
richten ist m5glich. 

MMS ist Uber die Nutzung von WAP realisierbar . Dabei wird ftir 
die Funktibertragung von Daten, etwa von Multimedia Messages 

30 (MMs), das in Fig. 1 dargestellte Protokollschema (WAP WSP: 
Wireless Session Protocoll) angewandt. Dieses umfaBt eine E- 
bene 2 eines D^tenversenders (auch als MMS User Agent A be- 
zeichnet), eine Ebene 3 eines Providers (, dessen Netzele- 
ment/ das den Service ausftlhrt, auch als MMS Relay bezeichnet 

35 wird) und eine Ebene 4 eines Empf angers (auch als MMS User 
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Agent B bezeichnet) • Die Ebene 2 des Datenversenders umfafit 
zumindest ein Telekonmmnikationsgerat 5, ebenso xnafaBt die 
Ebene 4 des Empf^gers ein Telekommunikationsgerat 6. Diese 
Telekommunikationsgerate 5,6 kbnnen beispielsweise als tlbli- 
5 che Bandies oder als Gerate mit weiteren Eingabe- oder Anzei- 
gefunktionen, wie etwa Laptops, ausgebildet sein. 

Eine im Telekoiumunikationsgerat 5 des Versenders verfaBte o- 
der iiber dieses weiterzuleitende Multimedia message abgekiirzt 
10 (MM) kann einen oder mehrere Einheiten (DatenscLtze 7), bei- 
spielsweise einzelne Bilder, Filmsequenzen, Texte oder ahnli- 
ches, enthalten. Die MM wird zxmachst als Anfrage-Sendung 9 
(diese trSgt im WAP-Protokoll den Namen M-Send.req) an den 
Provider (Ebene 3) versandt. 

15 

Von dort wird die eingegangene Sendiang 9 mit der Rticksendung 
10 (M-send,conf ) an den Versender (Ebene 2) quittiert. 

Zeitlich darauf folgend wird vom Provider (Ebene 3) die Infor- 
20 mation 11 (M-Notification.ind) an den Empf anger (Ebene 4) ge- 
sandt, mit der dieser dartUber informiert wird, dafi fUr ihn 
eine Nachricht beim Provider 3 zum Herunterladen bereitliegt. 

Hiertlber erhait der Provider 3 beispielsweise automatisch die 
25 quittierende Riickmeldung 12 (M-NotifyResp.req) vom Telekommu- 
nikationsgerat 6 des Empf angers (Ebene 4) • 

Erst auf Anforderung durch den Einpf anger, mit der Sendung 13 
(WSP GET.req) wird vom Provider die MM mit der Sendung 14 (M- 
30 retrieve.com) an den Empf anger weitergeleitet . 

Die Nachricht 15 (M-Acknowledge . ind) quittiert den Empfang 
der MM. 

Die abschlieBende Nachricht 16 (M-Deli very. ind) gibt eine 
35 Empfangsbestatigung an den Versender 2 zurllck. 



wo 02/058359 



PCT/EPOl/14617 



Zur Verwaltung der Sendungen 9, 10, 11, 12, 14, 15, 16 dienen 
die sog. Header- Felder, also der eigentlichen MM vorange- 
stellte Felder, in denen Informationen tiber die Herkunft, 
Sendezeit, DateigroBe und weitere Details enthalten sein kc3n- 
5 nen. 

ErfindungsgemaB ist die Anzahl der Header-fields erhoht, uia 
zumindest ein weiteres Feld 17, 18, 19, 20, 21, 22, 23 als 
Informations f eld (er) Uber charakterisierende Paraineter::4der MM 
10 informieren zu konnen und darin ein oder mehrere Identifizie- 
ningssignal (e) fUr diese(n) Parameter dem Empf anger 4 zusen- 
den zu kGnnen. 

Im Ausftihrungsbeispiel sind daftir (sh. Fig. 4) die mit 0x80 
15 bis 0x86 im Hexadezimal system adressierten Felder 17, 18, 19, 
20, 21, 22, 23 vorgesehen, um die Information tiber die Para- 
meter, die weiter unten noch naher beschrieben werden, aufzu- 
nehmen, Auch eine andere Anzahl und/oder Adressierung der zu- 
satzlichen Header-Fields ist mSglich. 

20 

Die zusatzlichen genannten Header-Fields 17, 18, 19, 20, 21, 
22, 23 sind zumindest in der Nachricht 11 (M- 
Notification^ind) , mit der der EmpfcLnger 4 tiber das Bereit-* 
stehen einer MM informiert wird, beigefttgt. Auch die Nach- 
25 richt 9 (M-Send.req) kann, wenn die zusatzlichen Parameter 
vom Versender 2 generiert werden, die zusatzlichen Header- 
Fields 17, 18, 19, 20, 21, 22, 23 enthalten (Fig. 2), ebenso 
die eigentliche MM-Zustellung 14 {M-Retrieve.conf ) (sh.^Fig. 
5) Oder weitere der Nachrichten 10, 12, 13, 15, 16. 

30 

Unter einem Datensatz 7 einer MM wird im folgenden ein ein- 
zelner Bestandteil einer MM verstanden, der durch seinen Typ 
(z.B. Standbild) und sein Format (z.B. JPEG) definiert ist, 
wobei im MMS auch eine Formatkonvertierung durch das MMS Re- 
35 lay 3 vorgesehen ist, durch die gewahrleistet wird, daB auch 
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Telekommiinikationsgerate 6 eines Kmpfangers 4, die niir be- 
stimmte Formate eines Typs \intersttttzen, auch nur mit diesen 
Formaten bedient werden. Beispielsweise kann ein Telekommuni- 
kationsgerat 6 nur Standbilder im JPEG-Format anzeigen, was 
5 es im Rahmen seiner Anmeldxmg dem MMS Relay 3 mitgeteilt hat. 
Das MMS Relay 3 konvertiert dann alle fUr diesen Empfanger 
eingehenden Standbilder in das JPEG-Format/ wodurch sich im 
allgemeinen die DateigroBe andert, Dieser Aspekt ist ftlr eine 
spatere Betrachtung der nach^-dieser Erfindung neuen Header- 
10 Felder relevant. 



Als Identifikationssignal konnen beispielsweise die folgenden 
Informationen Ober einen Datensatz 7 enthalten sein. Auch ei- 
ne cindere Anzahl von Informationen, etwa nur eine Auswahl aus 
15 den aufgefUhrten, kann vorgesehen sein. Die Informationen 
werden dem Empfanger einer MM optional bei Verwendung des 
WAP-Standards (Fig. 1) in der Benachrichtigung 11 (M- 
Notification.ind) , und damit vor Obertragung der eigentlichen 
Daten in der Multimedia message, zur VerfUgung gestellt. 

20 

Mogliche Parameter von zu libertragenden Daten, insbesondere 
einer MM, tiber die der Empfanger vorab informiert wird, sind: 

1. die Anzahl der enthaltenen Datensatze 7 der MM (auch 
25 implizit durch die Beschreibung der einzelnen Elemente 

der MM) , 

2. die jeweilige Gr5Be (in Octets) eines Datensatzes 7, 

3. der jeweilige Typ und .das Format eines Datensatzes 7, 

4. die jeweilige Content ID (Content IDentification) eines 
30 Datensatzes eventuell auch relativ zu der Content 

ID/Message ID der gesamten MM, 

5. der jeweilige Name eines Datensatzes, 

6. das Sub jet der gesamten MM, 

1 . die Verbindung eines Elements zu einem oder mehreren 
35 anderen Datensatzen 7 der MM, 
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8. die Verbindung der gesamten MM oder eines/mehrerer Da- 
tensatze 7 zu einer oder mehreren DRLs/URIs aufi%rhalb 
der MM und bel elnem solchen extemen Link optional die 
Gr5fie der zu ladenden Daten des/der aufgel5sten extemen 
5 Links • 

Mit Hilfe der neuen Header-Felder 17, 18, 19, 20, 21, 22, 23 
kann die Methode der detailed Notification" im MMS Tomgesetzt 
vind der Komfort des MMS fUr den Behutzer deutlich erhoht wer- 

10 den. Schon vor dem Laden einer MM und damit voraussichtlich 
schon bevor Kosten ftlr den Benutzer entstehen, wird dieser 
liber die Inhalte und die Zusammensetzung der MM detailliert 
informiert und kann entsprechend handeln, etwa dadurch, dafi 
er nur einzelne Datensatze 7 der MM hertinteriadt xind weitere 

15 ablehnt. 



Eine MM besteht grundsatzlich aus einem Header und abh^ngig 
vom Typ der MM zusatzlich aus einem Datenteil (WAP: Body) ♦ 
Der Header umfafit allgemeine Informationen der MM und setzt 

20 sich aus definierten Header- Feldern zusammen. Der Datenteil 
der Message enthait ein oder mehrere Elemente beliebigen Typs 
(z* B. Texte, Bilder, T5ne..-), die in beliebiger Reihenfolge 
dem Header folgen. Falls eine Prasentationsbeschreibung im 
Datenteil enthalten ist, soli in einer WAP-Message zu Beginn 

25 des Datenteils ein sogenannter Start-Parameter auf diese Pra- 
sentationsbeschreibung hinweisen. 

Jedes Header-Feld besteht aus einem Feld-Namen, gefolgt von 
einem Feld-Wert, der aus mindes tens, einem Octet besteht. Die 
Zuweisung von hexadezimalen Werten zu den Feld-Namen ist in 
30 Fig. 4 aufgeftlhrt. 



Ito die Benachrichtigung 11 an den Empfanger 4 mit den ge- 
wllnschten Informationen anzureichem, bestehen grundsatzlich 
zwei MOglichkeiten: Entweder werden die Informationen vom 
35 Provider 3 oder vom Versender 2 erstellt. Auch eine Mischform 
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ist meglich, Im einzelnen sind hierftir die folgenden Ablaufe 
mSglich: 

Die Infonaationen werden aus der am MMS Relay 3 mit der Nach- 
5 richt 9 eintref fenden MM extrahiert, d.h. teilweise aus Hea- 
der-Feldem unverandert Ubemommen und teilweise aus dem Da- 
tenteil der. MM berechnet (z.B. die Angabe der Gr5fie eines Da- 
tensatzes 7) . 

Vorteilhaft bei diesem Vorgehen ist die zu erwarteride Konsis- 

10 tenz zwischen den beschreibenden Header-Informationen der 
Nachricht 11 und den tatsachlichen Inhalten 14 (in WAP: M- 
Retrieve.conf ) / die auf Anforderung des Empf angers 4 (User 
Agent B) an diesen tibertragen werden. Der Realisierungsauf- 
wand beim Versender 2, vind damit i.d.R. im mobilen Endgerat, 

15 bleibt gering. Ein weiterer Vorteil besteht hinsichtlich der 
Genauigkeit der Grofienangabe, wenn Formatkonvertierung statt- 
findet. Bei MMS ist vorgesehen, daB vor Auslieferung der Da- 
ten eine Anpassung des Inhalts an z.B. Fahigkeiten des emp- 
fangenden MMS User Agents 4 (wie untersttitzte Codecs, Dis- 

20 play-Grofie des EndgerSts etc.) oder Vorlieben des Empf angers 
(wie automatische BeschrcLnkung auf eine maximale Grdfie) durch 
den Service Provider 3 stattfinden kann. Das MMS Relay 3 kann 
dem EmpfSLnger 4 die Grofie des Inhalts nach Datenanpassung 
mitteilen. Dies ist eine Information, die der Versender 2 

25 nicht besitzt. Nachteilig ist der beim MMS-Relay 3 zusatzli- 
che Aufwand zur Generierung der Informationen ftlr diese 
''detailed Notification'% der durch das notwendige '^Parsen'' 
der MM xind die Extraktion der entsprechenden Informationen 
entsteht. 

30 

Die Informationen k5nnen statt dessen bereits vom Versender 2 
generiert und als Header-Felder 17;18;19;20;21;22;23 in die 
Nachricht 9 zum Versenden einer MM (in WAP: M-Send.req) ex- 
plizit integriert werden. Vorteilhaft ist die unverlnderte 
35 Verarbeitung der MM im MMS Relay 3, das nicht den Inhalt der 



wo 02/058359 



PCT/EPOl/14617 



11 

MM analysieren muB. Die Realisierxmg der mit den neuen Hea- 
der-Feldem 17;18;19;20;21;22;23 eroffneten M5glichkeiten im 
Tenainal 5 kann vom Hersteller bestimmt werden. Es besteht 
dartlber hinaus die MOglichkeit, Endgerate mit unterschiedli- 
5 Chen Komfortmerkmalen anzubieten. Weiterhin kann der MM-- 

sendende Teilnehmer 2 sein Wissen tiber die interne und exter- 
ne VerknUpfiing der MM-Elemente dem MM-Empfanger in Form von 
detaillierten Infomiationen mitteilen, welche vom MMS-Relay 3 
lediglich weitergeleitet^^ Werden. Eine Generierung der Header- -vArv^v^ 
10 Felder im MMS Relay 3, die Wissen tiber die interne und exter- 
ne Verkniipfung der Datens^tze 7 erfordert, ware dort nur 
durch aufwendiges Parsen der MM m5glich* Nachteilig ist die 
Erweitening von Header-Feldern mit teilweise redundanten In- 
formationen. 

15 

Vorteilhaft werden die Informationen daher teilweise im sen- 
denden User Agent 2 und teilweise im MMS Relay 3 generiert, 
was auf Seiten des MMS Relay 3 auch die Aktualisierung be- 
reits vorhandener, vom Versender 2 generierter Header-Felder 
20 erfordert. 

FClr diese Mischform der Generierung zusatzlicher Informatio- 
nen kann folgende Aufteilung der im folgenden erklsLrten In- 
formationen vorgesehen sein: 

25 

Generierung im sendenden User Agent 2: 

• X-Mms-Content-ID: In ' der bisherigen WAP-Spezif ikation f^^- 
fehlen die MSglichkeiten, den Datensatzen 7 eigene zu- 

30 sSLtzliche Header-Felder zuzuordnen (z.B. mit jeweiligem 

Namen und Typ) und mehrere Datensatze 7 hierarchisch an- 
zuordnen. Fttr eine transparente Konvertierung einer MM in 
eine Internet-Mail (Format gemaB RFC 822 mit Erweiterun- 
gen gemafi MIME (Multipurpose Internet Mail Extensions) ) 

35 werden daher die hier folgenden Voraussetzungen vorge- 
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schlagen: Die zu jeder Extension einer E-Mail moglicher- 
weise zusatzlich im Datenteil der E-Mail codierten Infor- 

mationen (Name, Typ, ) sind transparent auch in einer 

MM enthalten. Eine Content-ID im Header der MM, die jedem 
5 Datensatz 7 eindeutig zugeordnet ist, kann als Verweis 

genutzt werden. Der Start-Parameter im Message-Body (= 
Datenstrukturabschnitt/ der eigentliche Mitteilungsinfor- 
mation(en) enthalt) muB als Feld definiert sein, das die 
Content-ID (= Inhaltsidentifikatorh^'rei des PrSsentations- 
10 beschreibungsobjektes enthalt und damit den Zugriff auf 

dieses Objekt ermc3glicht. Mit diesen Vereinbarungen ist 
eine transparente tfcertragung einer MM von einem MMS- 
Relay zu einem beliebigen Empfanger sowohl direkt tiber 
ein anderes MMS-Relay als auch liber das Internet per E- 
15 Mail moglich. Eine eindeutige Zuordnung zu dem Datensatz 

\ \ Oder den Datens^tzen 7 in der MM ist unbedingt ftir die 

erste Obertragung vom sendenden User Agent 2 zum MMS Re- 
lay 3 erf orderlich, 

• X-Mms-Content-Type: bezeichnet den Typ und das Format 
20 des Datensatzes 7. Diese sollten bereits beim Versenden 

eingetragen werden, da der Datensatz 7 nicht unbedingt 
einen Dateinamen wie in einer E-Mail erhait und dann 
nicht tiber die Dateierweiterung (Extension) einem Format 
zugeordnet werden kann* Eine Aktualisierung dieses Feldes 
25 durch das MMS Relay 3 ist nur bei einer Format- und/oder 

Typkonvertierung erforderlich. Der X-Mms-Content-Type 
wird durch den Wert Oder das Signal CTV angezeigt und be- 
Kj^^*"* - . stimmt • - "^ •• 

• X-Wfais-content-Size: GroBe des Datensatzes 7. Dieser wird 
30 durch Wert bzw. Inhalt CSV angezeigt und bestimmt. 

• X-Mms-Content-Name: Name des Datensatzes 7. Dieser Name 
ist nur dem sendenden User Agent 2 bekannt und muB daher 
von ihm eingesetzt werden. Ihm ist der Inhalt CNV zuge- 
ordnet . 
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• x-Mras-Extemal -Link- Flag: Zeigt an, dafl der Datensatz 7 
eine Verknfipfung auf Inhalte aufierhalb der MM enthSlt. 
Wenn diese Information vom sendenden User Agent 2 einge- 
setzt wird, ist eine Inhaltsanalyse des Datensatzes 7 

5 durch das MMS Relay 3 entbehrlich. Ihm ist inhaltlich der 

Wert Oder die Zeichenfolge ELF zugeordnet. 

• X-Itos-Extemal-Link-Size: Dam it wird die GrSfie eines 
verkntlpften Inhalts aufierhalb der MM angegeben. Dies wird 
durch den Inhalt ELS angezeigt. Da der Datenumfang eines 

10 externen Inhalts nicht an der Verkniipfung selbst abzule- 

sen 1st, ist diese Information ftlr einen Nutzer von gro- 
fiem Interesse. Sle kann direkt bei der Generierung der MM 
im sendenden MMS User Agent 2 erzeugt werden. Altemativ 
ist eine Generierung durch das MMS-Relay 3 mSglich, er- 

15 fordert jedoch neben der Analyse der gesamten MM auch den 

Zugriff auf in Referenz angeftihrte Objekt zwecks GrSBen- 
bestimmung. 

• X-^tois-Content-Related-URI : Die Information CRV dieses 
Feldes zeigt den Ort eines anderen Elements, auf das der 

20 Datensatz 7 Bezug niramt/ an. Beispielsweise enthalt ein 

Datensatz 7 eine Prasentationsbeschreibung, die sich auf 
andere Elemente mit Audio- , Video- Oder anderen Inhalten 
der MM bezieht. Die Generierung dieser Informationen er- 
fordert einerseits Wissen tiber die internen Beztige der E- 

25 lemente einer MM, das auf Seiten des sendenden MMS User 

Agents 2 vorhanden ist, und andererseits Wissen beztiglich 
der Positionen der MM-Elemente beim MMS-Relay/Server 3 
bzw. beim Empf anger 4. Die Informationen konnen auf Sei- 
ten des sendenden MMS User Agents 2 in Header-Feldern co- 

30 diert werden .xmd < sind durch das MMS-Relay 3 auf Basis der 

dann aktuellen Positionen zu korrigieren/aktualisieren 
und anschlieBend im empfangenden MMS User Agent 4 auszu- 
werten. 



35 Generierung bzw. Aktualisierung im MMS Relay 3: 
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• X-Mos-Content-ID: Wird bei Veranderungen Content- ID 
durch das 'MMS- Relay angepafit. 

• X-Mms-Content-Type: Falls das MMS Relay 3 den Typ 

5 und/oder das Format eines Datensatzes 7 andert, erfolgt 

die entsprechende Aktualisierung des Content-Type. 

• X-Mias-Content-Size: GrdJBe des Datensatzes 1, angegeben 
in Octets. Nur falls das MMS Relay 3 Typ land/oder Format 
des Datensatzes Sindert, erfolgt eine Aktualisierung der 

10 die Content-Size betreffenden Information. 

Mit den differenzierten Informationen, die ein Benutzer 4 mit 
der Nachricht 11 (WAP: M-Notification.ind) erhalten hat, ist 
tab^er den beispielsweise softwareseitig in einem Mentt i.mple- 

15 mentierten und tlber ein Eingabemittel, etwa eine Tastatur, zu 
bedienenden Auswahlschalter 25 ein Zugriff auch auf einzelne 
DatensSitze 7 m5glich. So kann ein partielles Download durch 
eine Downloadanforderung mit der Content-ID eines jeweils ge- 
wtinschten Datensatzes 7 (beispielsweise eines Fotos ohne 

20 gleichzeitige Mittlbertragung des Begleittextes) in WAP mit 
dem Befehl 13: WSP GET.req versoilafit werden. 

Um dieses zu ermoglichen, muB das grundsatzliche Problem ge- 
lost werden^ dafl die zusatzlichen Header-Felder teilweise in 
25 einer MM mehrfach verwendet werden miissen (WAP: z.B, X-Mms- 
Content-Name fUr jeden Datensatz 7 der MM) . Stehen mehrere 
Header-Felder in einem inhaltlichen Zusaimaenhang, was bei der 
Beschreibung eines Datensatzes der Fall ist, mufi auch eine 
syntaktische Zuordnung definiert sein. 

30 

Grundsatzlich ist im WAP-Standard die Reihenfolge der Header- 
Felder unerheblich. Eine Veranderung der Reihenfolge der In- 
formationen Name, GroBe, Typ und/oder URI mehrerer Datensatze 
7 wUrde damit eine Veranderung bzw. Verfalschung der Be- 
35 schreibungen der Datensatze 7 bewirken, wenn man die Zuord- 
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nvmg der Infonnationen von der Reihenfolge der Header- 
Elemente abhSngig machte, was der einzig gangbare Weg ist, da 
eine hierarchische Struktur der Header-Elemente in WAP nicht 
vorgesehen ist. 

5 Andererseits steht die Aussage der Irrelevanz der Header- 
Element-Reihenfolge im Widerspruch zu der Aussage, dafl HTTP- 
Header, die Listen enthalten, in mehrere WSP-Header mit je- 
weils nur einem einzigen Element umgewandelt werden sollen/ 
wobei die Reihenfolge der Eintrage erhalten bleiben soli. Urn ' 
10 diesen Widerspruch aufzulosen, wird eine Systematik entwor- 
fen, die die Signifikanz der Reihenfolge der Header-Elemente 
voraussetzt . 

Zur Abgrenzung der Beschreibungen einzelner Datensatze 7 mu5 
15 ein definiertes Header-Feld die Beschreibiing eines Datensat- 
zes 7 beginnen, der alle nachfolgenden Header-Felder zugeord- 
net werden, bis entweder das Ende des Headers der Message er- 
reicht ist oder ein nachstes Header-Feld des definierten Typs 
den Beginn der Beschreibung eines weiteren Datensatzes 7 mar- 
20 kiert, 

Als definiertes Header-Feld far die Beschreibung eines Daten- 
satzes 7 dient das Feld 17: X-Mins-Content-ID, da es die ein- 
deutige Adresse des Elements enthalt. Die Beschreibung eines 
25 Datensatzes 7 wird grundsatzlich durch dieses Feld eingelei- 
tet, worauf die weiteren Felder optional und in beliebiger 
Reihenfolge erscheinen kOrmen. 

Alternativ zu der Systematik mit eindeutigen Marken ftir die 
30 Message-Elemente - den Content-IDs - und den entsprechenden 
Verweisen im Header ist auch eine Systematik mSglich/ die mit 
der Angabe eines Offsets bis zu dem beschriebenen Datensatz 
im Datenteil der MM arbeitet. Nachteilig sind dabei aller- 
dings zum einen die Gefahr, den Offset nicht korrekt zu be- 
35 rechnen bzw. bei einer moglichen Format konvertierung im MMS 
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Relay 3 nicht korrekt anzupassen, und zum anderen die fehlen- 
de MSglichkeit, eine logische Beziehiing zwischen einer Be- 
schreibxmg eines Datensatzes 7 in der Benachrichtigxing 11 und 
in der tatsSchlichen tJbersendxing 14 der MM herzustellen. Die 
5 Informationen mOBten dann in der zugestellten Multimedia Mes- 
sage noch eiiuaal enthalten sein. 

Der Versender (Ebene 2) kann an seinem Telekommunikationsge- 
rat 5 eine hardwareseitig oder insbesondere sof twareseitig^ 

10 und tlber die ohnehin vorhandene Tastatur zu bedienende Einga- 
bemoglichkeit bet^tigen, um dam it in den Header- Feldern 17, 
18, 19, 20, 21, 22, 23 die zusatzlichen Informationen oder 
einen Teil dieser Informationen (s.o.) zu hinterlegen. Diese 
werden als Bestandteil eines Identifizierungssignals ftir ei- 

15 nen oder mehrere Datensatze 7 der MM mit der Sendung 9 (in 
WAP: M-Send.req) (Fig. 1) an den Provider (Ebene 3) gesandt. 
Die Bestatigung des Versands durch das MMS-Relay 3 (in WAP 
mit der Nachricht 10: M-Send.conf) bleibt unverSndert, da die 
einzige wesentliche Information die optional vom MMS-Relay 3 

20 vergebene Message- ID ist. 

Der Empf^ger 4 erhalt dann die Nachricht 11 (in WAP M- 
Notification.ind) / daB ftir ihn eine MM mit einem oder mehre- 
ren Datensatzen 7 zum Herunterladen bereitliegt. Diese Be- 

25 nachrichtigung 11 enthait wiederum alle zusatzlichen Header- 
Felder 17, 18, 19, 20, 21, 22, 23 zur Beschreibung der Daten- 
satze 7 aus dem Header der Nachricht 9 zu ihrem Versenden (in 
WAP: M-Send.req). Diese Information kann dem Empf anger op-.. . 
tisch (tlber das Anzeigemittel 24, beispielsweise das Display) 

30 Oder akustisch mitgeteilt werden. 

Die Bestatigiing 12 (WAP: M-NotifyResp.ind) des Empfangs der 
Notification 11 bleibt unverandert. 

Nachdem der Enqpfanger 4 der MM detailliert tlber deren Inhalt 
35 informiert ist, kann er die gesamte MM (in WAP: durch das 
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Kommando 13: WSP Get.req) herunter laden. Alternativ ist nach 
dieser Erfindung aucdi ein Zugriff auf ein einzelnes Element 
der MM moglich. Hierzu wird beispielweise als URI die Con- 
tent-ID eines Datensatzes 7 der MM in das Kommando zum Down- 
5 load eingesetzt. Ohne Zustimmixng des Rntpfangers 4 wird ein 
Herxinter laden der MM (Obersendiing der Sendung 14 an den Emp- 
f anger) nicht freigegeben. Auch ist es moglich, daB der Emp- 
fanger 4 die MM erst zu einem spateren, billigeren Zeitpunkt 
ilbermittelt bekommen wiTl.- 

10 

Die eigentliche Datensendung 14 kann die beschreibenden Hea- 
der-Felder 17, 18, 19, 20, 21, 22, 23 enthalten. Dies ist je- 
doch nicht zwingend , wie in Fig. 7 dargestellt. 

15 Schliefilich schickt das MMS-Relay 3, wenn vom Versender 2 ge- 
wiinscht, eine Mitteilung 16 Ober den Status der Zustellung 
der MM (in WAP: M-Delivery, ind) an diesen. Neben den bisher 
schon bekannten Moglichkeiten ''Expired'' (verfallen) , "^Retrie-- 
ved^' (zugestellt) , '•Rejected" (abgelehnt) , ""Deffered^' (verzo- 

20 gert)" kann erf indungsgem^B auch "Partly-retrieved^' (partiell 
zugestellt) im Statusfeld auftreten. Es wird angezeigt, wel- 
cher Datensatz 7 zugestellt wurde. Der entsprechende Ab- 
schnitt der Nachricht 16 konnte wie folgt lauten: 

25 >»» 

7.2.22 Status field (Status-Feld) 

Status-value = Expired | Retrieved | Rejected | Deferred | Partly-retrieved 
Expired = <:Octet 128> 
Retrieved = <Octet 129> 
3 0 Rejected = <Octet 1 30> 
Deferred = <Octet 131> 
Partly-retrieved = <Octet 132> 
««< 

Die ebenfalls neuen Felder 22, 23 
35 X-Mms -External-Link- Flag (optional) und 
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X-Mnis-External-Link-Size (optional) 

kbnnen in den Nachrichten 9 zim Versand der MM (WAP: M- 
Send.req) irnd in der Nachricht 11 an den En^jf anger 4 (WAP: M- 
Notification.ind) die im Inhalt der MM enthaltenen Links auf 
5 Inhalte auBerhalb der MM anzeigen. Je nach Position im MM 

Header zeigt das Feld 22: X-Mios-Extemal-Link-Flag einen Link 
auf externe Inhalte innerhalb der gesamten MM oder innerhalb 
eines bestimmten Datensatzes 7 der MM an. Das Feld 23: X-Mms- 
External-Link-Size beschreibt optional die Grofie des Inhalts 
10 in Octets. Dam it kann der Empf anger der Notification bereits 
abschatzen, welches zusatzliche Datenvolxamen zu dem der MM 
selbst noch herunterzuladen ist. 

Das vorgestellte Verfahren kann in eine Software zum Betrei- 
15 ben des jeweiligen Kommunikationsstandards, etwa UMTS, integ- 
riert sein. Die Telekommunikationsgerate 5,6 sind dann mit 
einer entsprechenden Software versehen. 

Im folgenden ist ein konkreter Ablauf der erf indungsgemafien 
20 Obermittlung einer MM nach dem WAP-Standard (Fig. 1) darge- 
stellt: 

Es wird beispielhaft folgendes Szenario angenommen: Versender 
2 (Markus Trauberg) verschickt eine MM mit einem Text mit 

25 mehreren Datensatzen 1, namlich einem MP3-AudiO/ einem JPEG- 
Bild, einem MPEG-4-Video und einer SMIL-Prasentationsbe- 
schreibung, an zwei Empfanger 4 (Andreas Schmidt und Josef 
Laxamen) . Zur komfortablen und dif f erenzierten Nutzung durch 
die Empfanger 4 ftigt er Beschreibungen von Parametern der Da- 

30 tensatze 7 der MM ihrem Header bei. Die Daten werden in den 
Nachrichten 9 (M-Send.req) und 11 (M-Notification.ind) an die 
Empfanger ubertragen. Empfanger 4 Andreas Schmidt ladt die 
komplette MM auf sein Endgerat 6, wahrend Enqpfanger 4 Josef 
Laumen nur an dem Text interessiert ist und nur diesen auf 
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sein Endger^t 6 ladt. Die folgenden MMs werden zwischen den 
Einheiten tlbertragen: 

f 

MM wird an zwei Adressaten verschickt. Dann kann das Nach- 
5 richtenprotokoll wie in Figur 9 abgebildet sein. 

In der MM sind im Header die zusStzlichen InformationsblScke 
tlber die MM-Elemente codiert. Darin werden auch die Beziehun- 
gen "zwischen den Datens^tzen 7 der MM beschrieben: So enthalt 

10 die Beschreibung der presentation_description Verweise auf 
die darin externen Elemente image/ jpeg, audio/mp3 und vi- 
deo/iapeg4 in Form der entsprechenden Content-IDs. 
Die Beschreibung des Textes enthalt die Information, daB ein 
Verweis auf ein externes Objekt enthalten ist^ das 8245 Byte 

15 Daten umfafit. 

Die Quittierung der oben auf gefiihrten Sendeanfrage 9 (M- 
Send.req) des Versenders 2 erfolgt mit der Nachricht 10 (M- 
Send.conf) vom MMS Relay 3. Diese Nachricht 10 enthalt keine 
20 zusatzlichen neuen Felder, wie an ihrer folgenden Aufstellung 
sichtbar ist, die in Figur 10 abgebildet ist. 

Das MMS Relay 3 bestatigt mit Nachricht 10, daB die Anfrage 9 
fehlerfrei zum MMS Relay 3 tibertragen worden ist. Es wird die 

25 Transaction-ID#l benutzt, um die Nachricht 10 beim Versender 
2 eindeutig der dazugehorigen Anfrage 9 (M-Send.req) und da- 
mit der gesendeten MM zuzuordnen. Weil in der Nachricht 9 in 
dem Feld X-Mms-Delivery-Report ein Zustellungsreportc^angefor- 
dert wurde, weist das MMS Relay 3 der MM eine Message-'ID zu 

30 und Uberrndttelt diese hier an den Versender 2. 

Im welter en wird die Nachricht 11 an die Empf anger 4 tibertra- 
gen: 

35 M-Notification.ind (MMS Relay MMS User Agent B) : 
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Im MMS ist vorgesehen, einen Empfanger einer MM iiber neue 
Nachrichten, die fUr ihn vorliegen, zu inf ormieren. Die Nach- 
richt 11 (M-Notification.ind) dient der Benachrichtigung der 
5 Adressaten tiber zum Download bereitliegende MM. Folglich e- 
xistieren in diesem Beispiel zwei Benachrichtigtmgen an die 
Empfanger Andreas Schmidt und Josef Latimen. Jede enthait eine 
eigene Transact ion- ID. Die Information tiber den Speicherplatz 
der MM steht bei beiden in dem Feld X-Mms-Content-Location. 

10 

Figur 11 gibt den Inhalt der M-Notification-ind exemplarisch 
wieder . 

Neben den tiblichen Feldem zu Beginn der Nachricht 11 k5nnen 
15 nun alle beschreibenden Elemente der Nachricht 9 in die Nach- 
richt 11 llbemonmen werden. ZusSLtzlich werden, wie oben an- 
hand der Mischform beschrieben, durch das MMS Relay 3 noch 
die Informationen X-Mms-Content-Type und X-Mns-Content-Size 
aus den Informationen des Body der Nachricht 9 generiert. Der 
20 Empfanger 4 kennt nach Erhalt der Nachricht 11 sowohl die Ad- 
resse der MM (wie bisher) als auch die Zusammensetzung aus 
den einzelnen DatenscLtzen 7 \ind deren Content-IDs. Bin 
Zugriff ist daher auch separat auf einzelne Datensatze 7 der 
MM mdglich. 

25 

Der korrekte En^fang der Benachrichtigung wird anschlieBend 

von dem Empfanger 4 der MM mit der Nachricht 12 (M- 

NotifyResp.ind) bestatigt, indem die entsprechende Transacti- 
ve . 

on-ID der Nachricht 11 zusammen mit einer Statusmeldung zu- 
30 rtick zum MMS Relay 3 geschickt wird. 

Der Download der MM wird durch das Komtaando 13 (WSP GET.req) 
veranlafit. Die MM wird darauf vom MMS Relay 3 in der Nach- 
richt 14 (M-Retrieve.conf ) zum Empfanger 4 gesendet. 
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Da die Informationen Uber die einzelnen Elemente bereits mit 
der Nachricht 11 tibertragen wurden, kann der Download der ge- 
samten MM wie bisher mit der Nachricht 14 erfolgen, ohne daB 
zusatzliche Felder im Header dieser Nachricht 14 eingefiigt 
5 werden mtlssen. Die zusatzlichen Informationen in den Headern 
der einzelnen Datensatze 7 hingegen sollten auch in der Nach- 
richt 14 enthalten sein, da sie wichtige Informationen tiber 
die MM-Datensatze 7 enthalten. 

10 Im folgenden sind zwei mogliche Reaktipnen der Empf anger 4 
beispielhaft dargestellt: 

Empfanger Andreas Schmidt ladt die gesamte MM. 
Empfanger Josef Laumen ladt nur den Textteil der MM auf sein 
15 Empfangsgerat 6. 

Im erst en Fall wird die Nachricht 14 wie in Figur 12 abgebil- 
det codiert: 

20 Der Empfanger 4 Andreas Schmidt quittiert den erfolgreichen 
Empfang der MM anschlieBend Nachricht 15 (M-Acknowledge . ind) . 
Mit der darin enthaltenen Transaction-ID 1st am MMS Relay 3 
die Zuordniing zu der gesendeten MM entsprechend dem Informa- 
tionssignal M-Acknowledge . ind von Figur 13 moglich. 

25 

Als letzter Schritt der Transaktion wird schlieBlich die 
Nachricht 16 (M-Delivery.ind) entsprechend Figur 14' vom MMS 
Relay 3 an den Versender 2 tlbermittelt : 

30 Der zweite En^fanger Josef Laumen hingegen entscheidet sich 
daftlr, nur den Textteil der Nachricht 14 zu laden. Dazu setzt 
er in die Nachricht 13 (WSP GET.req) die Conteht-ID des Text- 
teils ein: 000714. 1412. Imarkus. trauberg" . Er erhait diesen 
Textteil mit der Nachricht 14 (M-Retrieve.conf ) , die gegen- 
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tlber der Version an Andreas Schmidt deutlich verandert ist 
und deren Inhalt in Figur 15 exenqplarisch wiedergegeben ist. 

Die Nachricht 14 wurde gegentlber ihrer kompletten Version, 
5 wie sie an Andreas Schmidt geschickt wurde, urn die nicht er- 
wUnschten Datensatze 7 reduziert. Aufierdem wurde das Feld 
nEntries entsprechend angepaflt. 

Dfe Nachricht 15 (M-Acknowledge.ind) , die in Figur -16 darge- 
10 stellt ist, entspricht fast komplett der Version an Andreas 
Schmidt, enthait aber eine eigene Transaction- ID: 

Als letzter Schritt erfolgt wieder die Benachrichtigung des 
Versenders 2 iiber den Status der Zustellung* Sie enthalt den 
15 Status der partiellen Zustellung ("Partly-retrieved'^ ) und ist 
inhaltlich in Figur 17 dargestellt. 

Neben den vorstehend beschriebenen Moglichkeiten zur detail- 
lierten Benachrichtigung von Empfangern von Multimedia Nach- 
20 richten (MMs) im Multimedia Messaging Service (MMS) besteht 
eine weitere, zweckmaBige Option, die Vorteile gegeniiber den 
bereits vorgestellten Varianten hat* Diese vorteilhafte Opti- 
on wird nachfolgend beschrieben, 

25 Kern dieser Modifikation ist die Realisierung der Idee, den 
jeweiligen Empf anger detailliert tlber den Inhalt der jeweili- 
gen MM zu informieren, wobei lediglich ein einziges, neu de- 
finiertes Header-Feld genutzt wird, fiir das neue- Parameter 
eingeftihrt werden. Das neue Header-Feld enthalt dabei alle 

30 Parameter, d*h. Informationen tlber ein zu beschreibendes Ele- 
ment der MM. Unter Element bzw. Datensatz einer MM wird in 
dieser Erfindungsmeldung ein einzelner Bestandteil einer MM 
verstanden, der insbesondere durch seinen Typ (z.B. Stand- 
bild) und sein Format (z.B. JPEG (= joint photographies ex- 

35 pert group)) definiert ist. 
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Die folgende Liste enthalt die bereits zu den vorausgehenden 
Varianten vorgeschlagenen Informationen, die dem Empf anger 
einer MM optional in einer Empf angerbenachrichtigung im MMS 
(M-Nind; in WAP: M-Notification.ind) zur VerfUgung gestellt 
5 werden k5nnen. Dazu gehOren: 

• die Anzahl der enthaltenen Elemente der MM (auch implizit 
durch die Beschreibimg der einzelnen Elemente der MM) , 

• die GrOfie (in Octets) eines Elements/ 

• der Typ und das Format eines Elements, 

10 • die Content ID (Content IDentification) eines Elements (= 
Name bzw. Bezel chner des jeweiligen Header feldes des je- 
weiligen Identif ikationssignals) / 

• der Name eines Elements, 

• die Verbindung eines Elements zu einem oder mehreren ande- 
15 ren Element en der MM, 

• die Verbindting der gesamten MM oder eines/mehrerer Elemen- 
te zu einer oder mehreren URLs/URIs (uniform resource 
link/identifier) aufierhalb der MM und bei einem solchen 
extemen Bezug optional die Gr5Be der zu ladenden Objekte 

20 des/der aufgelGsten extemen Beztige. 



Die Definition der entsprechenden Header- Felder zur optiona- 
len Erweiterving der MMS Kmpf angerbenachrichtigung (M-Nind; in 
WAP: M-Notification.ind) und gegebenenfalls auch der MMS Sen- 
25 deanfrage (M-Sreq; in WAP: M-Send.req) und der MMS- 
Zustellnachricht (M-Rconf; in WAP: jW-i^etrieve. conf; sind im 
beim nachfolgeiiden Ausftlhrungsbeispiel beschrieben. ^isiii,r 



Eine MM besteht grundsStzlich - wie in den vorausgehenden 
30 Ausftihrungsbeispielen aufgezeigt - aus einem Header und ab- 
hangig vom Typ der Nachricht ggf . zusStzlich aus einem Daten- 
teil (WAP: Body) . Der Header umfasst allgemeine Informationen 
der Nachricht und setzt sich aus ein oder mehreren, definier- 
ten Header-Feldem zusaramen. Der etwaige Datenteil der Messa- 
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ge enthait ein Oder mehrere Elemente beliebigen Typs, die in 
beliebiger Reihenfolge dem Header folgen. Falls eine Prasen- 
tationsbeschreibung im Datenteil enthalten ist, soil z.B. in 
einer WAP-Nachricht zu Beginn des Datenteils ein so genannter 
5 Start-Parameter auf diese Prasentationsbeschreibung zweckma- 
fiigerweise hinweisen. 

Figur 1 zeigt dabei in einem Nachrichtenf lussdiagram den 
• prinzipiellen Ablauf einer Nachrichteniibennittliing von der 
10 Nutzerapplikation des sendenden Nutzers 2 {User Agent A - M- 
UA_A) Ober die MMS Verbindimgseinheit 3 (MMS Relay=M-SR) zur 
Nutzerapplikation des empfangenden Nutzers 4 (User Agent B 
==(M-UA_B) ) . 

15 Die je nach Nachrichten-Typ m5glichen bzw. erforderlichen 

Header-Felder in WAP sind ftir die hier betrachteten Nachrich- 
ten-Typen in den Tabellen entsprechend der Figuren 21 A/21B 
und 22 dargestellt. Diese wurden WAP--209"MMSEncapsulation, 
Release 2000; Wireless Application Protocol; WAP Multimedia 

20 Messaging Service; Message Encapsulation; MMS Proposed SCD 

1.0 entnommen. Nach WAP-203-WSP^ Version 4-May-2000; Wireless 
Application Protocol, Wireless Session Protocol Specificati- 
on; Chapter 8*4: ''Header Encoding'' besteht jedes Header- Feld 
aus einem Feld-Namen, gefolgt von einem Feld-Wert, der aus 

25 mindestens einem Octet besteht. Die Zuweisung von hexadezima- 
len Werten zu den Feld-Namen der WAP Messages ist in der Ta- 
belle entsprechend Figur 20 aufgeftihrt. 
^^,Diese weitere Option beruht auf der zu den.,..yorausgehenden 
Ausftihrungsbeispielen eingeftihrten Definition eines Header- 

30 Feldes zur eindeutigen Kennzeichnung eines Elementes einer 
MM, dem Header-Feld X-Mms-Content-IDr das im Body der MM dem 
Element der MM als Header-Feld voransteht und das Element 
eindeutig Jcennzeichnet . 
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Abweichend von den vorausgegangenen Vorschlagen basiert die 
Beschreibung eines Elementes der MM hier auf einem einzigen 
Header-Feld X-Mms-Content-ID^ das in den Header der MM zur 
Benachrichtigung des EmpfSngers integriert wird, iind das die 
5 notigen Inf ormationen (fUr die Benachrichtigixng des Empf^- 
gers z.B. iiber Anzahl, Typ, Grofie, Format der fUr ihn bereit-- 
gehaltenen Datensatze der MM) durch einen Oder mehrere Para- 
meter aus der folgenden Liste beschreibt. 
•--^Name beschreibt den Namen des MM-Elements;'-'- 
10 • Type beschreibt den Typ und das Format des MM-Elements; 

• Size beschreibt die GrSBe des MM-Elements in Bytes; 

• External-Link zeigt an, dass das Element eine Verkniipfung 
auf Inhalte aufierhalb der MM enthalt; 

• External -Link-Size gibt an, welches Datenvolumen zum Auf- 
15 losen der externen Referenz zusatzlich herxmtergladen wer- 

den mufi; 

• Jleiated-JD gibt an, welches Element der MM mit dem Ele- 
ment in Bezug steht \md bei einem partiellen Herunteralden 
der MM ebenfalls geladen werden sollte (Mehrfachverwendung 

20 mdglich* 

Allgemein ausgedrtlckt wird also jetzt das Identifikationssig- 
nal fUr einen oder mehrere zugeordnete Datensatze in einem 
einzigen, zus^tzlichen Headerfeld vom jeweiligen Sender wie 

25 z.B. einem ersten Mobilfimkger^t und/oder zust&:idigen Server 
in einer MMS EmpfSngerbenachrichtignng zum Empfanger wie z.B* 
zu einem zweiten Mobil funkger St codiert tlbertragen. Dadurch 
sind Reihenfolgen- und Zuordnungsprobleme, wie sie etwaig bei 
der Verwendung mehrerer Headerfelder zwischen diesen selbst 

30 und/oder den zugeordneten Datensatzen auftreten kSnnten, von 
vomherein vermieden. 
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Weiterhin sollen zusatzlich zu den bereits zu den vorausge- 
henden Ausfiihningsbeispielen beschriebenen auch folgende In- 
formationen als Parameter codiert werden konnen: 

1. Original -Type beschreibt den Typ des MM-Elements vor 
5 der Transcodierimg durch die MMS Verbindungseinheit (M- 

SR); 

2. Original-Size beschreibt die GrSBe des MM-Elements vor 
der Transcodierung d\jLrch die MMS Verbindungseinheit (M- 
SR) in Bytesr 

10 

Durch die Zusammenfassung aller fiir ein MM-Element relevanten 
Informationen in einem einzigen Header-Feldf kaim auf eine 
Einhaltvmg der Header-Reihenfolge, wie sie bei den vorherge- 
henden Ausftlhrungsbeispielen vorausgesetzt wird/ verzichtet 
15 werden. 

In Figur 18 ist das zum Zwecke der detaillierten Benachrich-- 
tigung des Empf angers einer MM gemMB WAP neu eingefOhrte/ 
einzige Header-Feld einschlieBlich der Codierung von Feld- 

20 Name und Feld-Wert aufgeftlhrt. Die Tabelle entsprechend Figur 
20 enthait die Zuweisung von hexadezimalen Werten zu den 
Feld-Namen. Die Taibelle entsprechend Figur 19 enthalt die Zu- 
weisung von hexadezimalen Werten zu den Parameternamen und 
weiterhin die zur Codierung der Parameterwerte zu verwenden- 

25 den Typen. Die urn die entsprechenden Header- Felder ergSinzten 
WAP Nachrichten sind in den Tabellen 21A/21B und 22 aufgelis- 
tet. Alle VerSnderungen und ErgSnzungen in den Tabellen zum 
heutigen Stand der Technik sind dabei eingerahmt. 

30 Ausf Uhrungsbeispiel : 

Im nun folgenden Ausflihrxingsbeispiel, das auf der Definition 
der beschriebenen Nachrichten durch das WAP-Forim basiert, 
wird detailliert auf die in den WAP Nachrichten benutzten 
Header- Felder eingegangen. Dabei wird beispielhaft folgendes 

35 Szenario angenommen: M-UA_A (Markus Trauberg) verschickt eine 
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Multimedia Message MMa bestehend aus einem Text, einem MP3~ 
Audio, einem JPEG-Bild, einem MPEG-4-Video und einer SMIL 
(synchronized multimedia integration language)- 

Prasentationsbeschreibung an einen Empfanger M-C7A_B (Andreas 
5 Schmidt) . Zxor komfortablen und differenzierten Nutzung durch 
den Empfanger werden Beschreibungen der Elemente der MM dem 
Header der MM gemcUB dieser Erf indungsmeldung zugeftigt. Die 
Daten werden in den Nachrichten M-Sreg und M-Nind an den Emp- 
fanger tibertragen. Empfanger Andreas Schmidt ladt die kom- 
10 plette MM auf sein Endgerat. Die folgenden Nachrichten werden 
zwischen den Einheiten tibertragen. 

MMa wird an einen Adressaten verschickt. Deren Inhalt ist in 
Figur 23 beispielhaft abgebildet. 

15 

In der Message sind im Header die zus^tzlichen Inf ormations- 
blocke, d.h. allgemein ausgedrtickt die ein oder mehreren Pa- 
rameter Uber die MM-Elemente codiert. Darin werden auch die 
Beziehungen zwischen den Elementen der MM beschrieben: So 
20 enthalt die Beschreibiing der Prasentationsbeschreibung 
(*.smil) Verweise auf die darin referenzierten Elemente 
image/jpeg, audio/nqpS und video/mpeg4 in Form der entspre- 
chenden Content-IDs. 

Die Beschreibiang des Textes enthait die Information, dass ein 
25 Verweis auf ein extemes Objekt enthalten ist, das 8245 Byte 
Daten umfasst. 

Nach dem Stand der Technik wird die Sendeanfrage (WAP: M- 
Send.req) des MMS User Agent A mit einer Nachricht (in WAP:M- 
30 Send.conf) vom M-SR quittiert. Im Rahmen dieser EM wird diese 
Message nicht modifiziert und daher hier nicht aufgefuhrt. 

M-Nind (M-SR -> M-IIA-B) ; 
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Im MMS (multimedia sei^ices) entsprechend 3G TS 23.140 versi- 
on 3.0.1, Release 1999; Third Generation Partnership Project; 
Technical Specification Group Terminals; Multimedia Messaging 
Service (MMS); Functional Description; Stage 2 lond WAP-209- 
5 MMSEncapsulation, Release 2000; Wireless Application Proto- 
col; WAP Multimedia Messaging Service; Message Encapsulation; 
MMS Proposed SCD 1.0 ist vorgesehen, einen Empf anger einer MM 
iiber neue Nachrichten, die ftir ihn vorliegen, zu informieren. 
^Die Nachricht M-Nind (±n WAP: M-Notificatiomind) dient der 

10 Benachrichtigung der Adressaten tiber zum Herunterladen be- 

reitliegende MMs. Ihr Inhalt ist beispielhaft in Figur 24 ab- 
gebildet. Folglich existiert in diesem Beispiel eine Empfan- 
gerbenachrichtigung an den EmpfSnger Andreas Schmidt. Die In- 
formation tiber den Speicherplatz der MMa steht dabei in dem 

15 Feld X-Mas-Content-Location. 

Neben den Ublichen Feldern zu Beginn der Nachricht k5nnen nun 
alle beschreibenden, nach dieser Variante neuen Elemente der 
Nachricht M-Sreq in die Nachricht M-Nlnd tibernommen werden. 

20 Zusatzlich werden durch die M-^SR noch die Informationen Type 
und Size aus den Informationen des Body der Nachricht M-Sreq 
generiert bzw. wird das enthaltene Bild vom Typ image/ j peg in 
den Typ image/bmp konvertiert, da das Endgerat JPEG-Bilder 
nicht anzeigen kemn. Die entsprechenden Informationen tiber 

25 den ursprtinglichen Typ (Original-Type) und die ursprtingliche 
DateigrSfie (Original-Size) sind im entsprechenden Header-Feld 
erganzt worden. Der Empf anger kennt nach Erhalt der detailed 
.r^«Notification sowohl die Adresse der MM (wie bi'Sher) als auch 
die Zusammensetzung aus den einzelnen Elementen und deren 

30 Content-IDs. Bin Zugriff ist daher auch separat auf einzelne 
Elemente der MM moglich. 

Der korrekte Enqpfang der Benachrichtigimg kann anschlieBend 
von dem Empfanger der MWU mit der Nachricht M-iy^Rind bestatigt 
35 werden, indem die entsprechende Transaction-ID der M-Nind zu- 
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sainmen mit einer Statusmeldung zurttck zvm MMS Relay geschickt 
wird. Dann wird das Heriinterladen der 10^^ durch den Befehl W- 
Greq veranlasst. Die MM wird darauf vom M-SR in der Nachricht 
M-Rconf zim MM-UA A gesendet. 

5 

Im Folgenden wird die Nachricht von dem Empfanger Andreas 
Schmidt komplett auf sein Endgerat heriantergeladen. Die Nach- 
richt M-Rconf wird beispielsweise wie in Figur 25 codiert, 

10 Der Empfanger M-UA B quittiert den erfolgreichen Empfang der 
MMa anschliefiend gem^A Stand der Technik mit der Nachricht 

Zusammenfassend betrachtet wird somit ein Verfsihren zur tJber- 
tragimg zusatzlicher Informationen zur detaillierten Be- 

15 schreibung einer Multimedianachricht und der darin enthalte- 
nen MM-Elemente im Multimedia-Messaging-Service (MMS) bereit- 
gestellt. Diese Informationen werden insbesondere mit einem 
einzigen oder mehreren zusatzlichen Header-Feldern in der je- 
weiligen MMS Ei^pfangerbenachrichtigung vom jeweilig zustandi- 

20 gen Server wie z.B. M-SR zum empfangenden User Agent tibertra- 
gen. Die nOtigen Informationen werden vorzugsweise vom sen- 
denden User Agent generiert und in der MMS Sendeanfrage von 
diesem codiert zum zustandigen Server Ubertragen. Zusatzlich 
Oder unabhangig hiervon kOnnen die nStigen Informationen auch 

25 vom zustandigen Vermittlungs-/Bereitstellungs-Server aus dem 
Datenteil der jeweilig zu versendenden MM extrahiert \ind dem 
Empfangenden User Agent in der MMS Empfangerbenachrichtigung 
codiert iibertr^gen werden, Vorzugsweise kann dem empfangendenvr.^ 
User Agent eine oder mehrere der folgenden Informationen tlber 

30 den Inhalt oder einzelne Elemente des Inhalts der zur Zustel- 
lung z,B. im zustandigen Server bereitliegendeh Nachricht 
mitgeteilt werden: 

• Anzahl der in der MM enthaltenen Elemente 

• GrSBe des Elements der MM (in Octets) 
35 • Typ und Format des Elements der MM 
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• Keimzeichnung des Elements (Content-ID bzw. URI) 

• Name des Elements 

• die Verbindung eines oder mehrerer Elemente zu elnem o- 
der mehreren anderen Elementen innerhalb der MM (z.B. 

5 zwischen Prasentationsbeschreibimg und PrSsentations- 

element) 

• die Verbindung eines Oder mehrerer Elemente zu Inhalten 
beliebiger Natur auBerhalb der MM (z.B. zu HTML/WML- 
Seiten) 

10 • die jeweilige Grofie der verkntlpften externen Elemente^ 
die zusatzlich zur MM selbst geladen werden kOnnen (in 
Octets) 

• der Typ und das Format des Elements vor einer Trans co- 
dierung durch die M-SR 

15" X • die GroBe des Elements vor einer Transcodierung durch 
die M-SR (in Octets) 

Insbesondere bildet dabei die Keimzeichnung des Elements 
(Content -ID bzw. DRI) den ersten Eintrag im einzigen Header- 
20 feld Oder den Inhalt des ersten Header feldes bei mehreren be- 
nutzten Headerfeldem pro Element bzw. Datensatz. 



Bevorzugt kcuin die Beschreibung eines Elements einer MM je- 
weils mit einem einzigen Feld ausgefilhrt werden, das per ein- 
25 deutiger Identifikationsnummer bzw. Bezeichner auf das Ele- 
ment im Datenteil der Multimedianachricht verweist, und das 
die weiteren Informationen.^ls Parameter auch noch und nicht 
in separaten Headerfeldem enthait. 

30 Der EmpfSnger einer MM kann vorzugsweise, nachdem er eine de- 
taillierte Benachrichtigung erhalten hat, auch nur einzelne 
Elemente der MM auf sein Endgerat laden. Genauso ist es ggf . 
moglich, dass die nach dieser Erfindung zusStzlichen Informa- 
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tionen der MMS EmpfSngerbenachrichtigung {M-Nind) auch im 
Header der MMS Zustellnacdiricht {M-Rconf) ergSnzt werden* 

Vorzugsweise kann das zusatzliche Header-Felder - weim nur 
5 ein einziges Headerfeld pro Datensatz verwendet wird - in WAP 
wie folgt codiert werden: 

Codierung des Feld-Namens X-Mms-Content-ID im Wertebereich 
zwischen 00X00 bis 0X7F, insbesondere als 0x19 gemaB der Ta- 
belle nach Figur 20. 
10 Codierung des Feld-Wertes von X-Mms-Content-ID gemaB Figur 9. 

Die Informationen als Parameter in diesem einzigen Header- 
Feld konnen insbesondere nach der Tabelle von Figur 19 co- 
diert werden. 



Hintergrundangaben zu WAP und MMS, insbesondere zu der en ein~ 
schl^giger Normenliteratur finden sich beispielsweise an fol- 
genden Stellen: 



15 



20 



25 



30 



[4] 



[3] 



[1] 



[2] 



3G TS 23.140 version 3.0.1, Release 1999; Third Ge- 
neration Partnership Project; Technical Specifica- 
tion Group Terminals; Multimedia Messaging Service 
(MMS) ; Functional Description; Stage 2 
WAP-209-MMSEncapsulation, Release 2000; Wireless 
Application Protocol; WAP Multimedia Messaging Ser- 
vice; Message Encapsulation; MMS Proposed SCD 1.0 
WAP-203-WSP, Version 4-May-2000; Wireless Applica- 
tion Protocol, Wireless Session Protocol Specifica- 
tion; Chapter B.4: ''Header Encoding^^.. 
WAP-Forum:'' WAP MMS Interworking with Internet E- 
mail; WAP-2 07-MmsInet Interworking" ; Draft Version 
Ol-Jun-2000. 



[5] 



3G TS 22.140 v.4.0.1 (Juli 2000) : 3rd Generation 
Partnership Project; Technical Specification Group 
Services and System Aspects; Service Aspects; Stage 
1 Multimedia Messaging Service. 



35 
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. [6] RFC822: "Standard for the Format of ARPA Internet 

Text Messages" r Crocker D., August 1982- URL: 
ftp : //ftp . isi , edu/in-notes/rf c822 . txt . 
[7] RFC2045: "Multipurpose Internet Mail Extensions 

5 (MIME) Part One: Format of Internet Message Bo- 

dies", Freed N., November 1996. 
URL : ftp : //ftp . isi . edu/in~notes/rf c2045 . txt . 
[81 RFC2046: "Multipurpose Internet Mail Extensions 

(MIME) Part Two: Media Types", Freed N., November < 
10 1996. URL: ftp://ftp.isi.edu/in-notes/rfc2046.txt. 

[9] RFC2047: "MIME (Multipurpose Internet Mail Extensi- 

ons) Part Three: Message Header Extensions for Non- 
ASCII Text", Moore K., November 1996. URL: 
ftp : //ftp. isi . edu/in-notes/rf C2047 . txt . 

15 Im Rahmen der Erfindungsbeschreibung ist der einfacheren 

Schreibweise halber im Kontext auf folgende, gangigen Akrony- 
me Bezug genommen wurden, die zum besseren Verstandnis mit 
Ihrer vollst&ridigen Bedeutung nachfolgend aufgelistet sind: 

20 GSM Global System for Mobile Communication 

MM Multimedianachricht (Multimedia Message) 

MMS Multimedia Messaging Service 

SMS Short Message Service 

UMTS Universal Mobile Telecommunication System 

25 WAP Wireless Application Protocol 

WSP Wireless Session Protocol 

MMS spezifische Abktlrzungen; 

30 M-UA MMS Nutzer Applikation 

M-SR MMS Verbindungseinheit 

M~Sreq MMS Sendeanfrage 

M-Sconf MMS Sendebestatigung 

M-Nind MMS Empfangerbenachrichtigung 

35 M-NRind MMS En4)f angerbenachrichtig\angsbestatigung 
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W-Greq MMS Zustellanfrage 

M-Rconf MMS Zustellnachricht 

M-Aind MMS Zustell\ingsbestatigung 

M-Dind MMS Zustellstatusbenachrichtigxing 
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Patentanspriiche 

1. Verfahren zur Datenilbertragung in einem Mobilfunknetz, 
insbesondere von Text- und/oder Bilddaten mit und ohne Ton, 
5 dadurch gekennzeichnet, 

daB den Daten zumindest ein Identif ikationssignal fUr einen 
Datensatz oder mehrere Datensatze zugeordnet und dieses oder 
diese Identif ikationssignal (e) an den Empf anger der Daten U- 
bertragen wird oder werden. 

10 ' 

2- Verfahren nach Anspruch 1, 
dadurch gekennzeichnet, 
daB das oder die Identif ikationssignal (e) vor tJbertragung des 
Oder der durch diese (s) charakterisierten Datensatzes oder 
15 Datensatze ubertragen wird und optisch oder akustisch anzeig- 
bar ist. 

■■ 

3. Verfahren nach Anspruch 2, 
dadurch- gekennzeichnet, 

20 daB der Empf anger des oder der Identif ikationssignal (e) aus- 
w^ilen kann, ob er die Obertragung der durch diese charakte- 
risierten Daten ganz oder teilweise zulSLBt. 

4. Verfahren nach einem der Ansprtiche 1 bis 3, 
25 dadurch gekennzeichnet, 

daB ein Identifikationssignal Information tlber die Art eines 
Datensatzes, insbesondere dessen Datenformat, enthcLlt. 

5« Verfahren nach einem der Ansprtiche 1 bis4, 
30 dadurch gekennzeichnet, 

daB ein Identifikationssignal Information tlber den Namen ei- 
nes Datensatzes enthait. 

6. Verfahren nach einem der Ansprtiche 1 bis 5, 
35 dadurch gekennzeichnet. 
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daB ein Identif ikationssignal Information uber den Inhalt ei- 
nes Datensatzes enthalt. 



7. Verfahren nach einem der 
5 dadurch gekennz 
dcLfi ein Identif ikationssignal 
nes Datensatzes enthalt. 



Ansprtiche 1 bis 6, 
e i c h n e t , 

Information iiber die GroBe ei- 



8. . Verfahren nach einem der Ansprtlche 1 bis 1, 
10 dadurch gekennzeichnet/ 

daB ein Identif ikationssignal Information iiber die Anzahl von 
Datensatzen innerhalb von tlbertragenen Daten enthalt. 

9. Verfahren nach einem der Ansprttche 1 bis B, 
15 dadurch gekennzeichnet, 

daB ein Identif ikationssignal Information tiber eine Verkntip- 
f\ing mit zumindest einem Datensatz innerhalb der gesendeten 
Daten enthalt. 

20 10. Verfahren nach einem der Ansprtiche 1 bis 9, 
dadurch gekennzeichnet, 
daB ein Identif ikationssignal Information liber eine Verknilp- 
fung mit zumindest einem Datensatz aufierhalb der gesendeten 
Daten enthalt - 

25 

11. Verfahren nach einem der Anspruche 9 Oder 10, 
dadurch gekennzeichnet, 

daB das Identif ikationssignal Information tUber die GrdBe des- 
jenigen Datensatzes oder derjenigen Datensatze, mit denen ein 
30 tibertragener Datensatz verknUpft ist, enthait. 

12. Verfahren nach einem der Anspruche 1 bis 11, 
dadurch gekennzeichnet, 

daB ein Identif ikationssignal Information tlber die Kennzeich- 
35 nung eines Datensatzes enthait. 
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13. Verfahren nach einem der Anspriiche 1 bis 12, 
dadurch gekennzeichnet, 

daB das Verfahren im Mobile Messaging Service (MMS) angewandt 
wird und die tibertragenen Daten als Mobile Messages (MM) aus- 
5 gebildet sind. 

14. Verfahren nach einem der AnsprUche 1 bis 13, 
dadurch gekennzeichnet, 

daB das Verfahren im Obertragxingsstandard UMTS (Universal Mo- 
10 bile Telecommunication System) , im GSM (Global system for mo- 
bile communication) , im GPRS (General packet radio service) 
und/oder im EDGE (Enhanced Data Rates for GSM enviroments an- 
gewandt wird. 



15 15 ♦ Verfahren nach einem der Anspriiche 1 bis 14, 

^ ' dadurch gekennzeichnet, 

daB das Oder die Identifikationssignal (e) einem oder mehreren 
Header-Feldem der tibertragenen Daten zugeordnet wird oder 
werden. 

20 

16. Verfahren nach einem der Ansprtiche 1 bis 15, 
dadurch gekennzeichnet, 

daB ein Identifkationssignal in zumindest einem zus&tzlichen 
Header-Feld abgelegt wird. 

25 

17. Verfediren nach einem der Ansprtiche 1 bis 16, 
dadurch gekennzeichnet, 

daB das oder die Identifizienmgssignal(e) zumindest teilwei- 
se vom Versender generiert und bei Obermittlung einer Multi- 
30 media message vom Versender (MMS user agent A) ziam Service 
Provider (MMS relay) tibersandt werden. 

18. Verfahren nach Anspmch 17, 
dadurch gekennzeichnet, 

35 daB der Versender eines oder mehrere der Header-Felder, X- 
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MMS-Content-ID, X-MMS- Content-Name, X-MMS-Content^Type, X- 
MMS-External-Link-Flag, X-MMS-External-Link-Size' generiert- 

19 • Verfahren nach einem der Ansprtiche 1 bis 18, 
5 dadurch gekennzeichnet, 

dafi das oder die Identif izierungssignaKe) zumindest teilwei- 
se aus dem vom Service Provider (MMS Relay) empfangenen Da- 
tensatz selbstSndig ermittelt wird oder werden 

10 20 • Verfahren nach Anspruch 19, 

dadurch gekennzeichnet, 
dafi das MMS Relay eines oder mehrere der Header-Felder X-MMS- 
Content-ID, X-MMS-Content-Size, X-MMS-Content-Type generiert 
Oder aktualisiert . 

15 

21. Verfahren nach einem der Ansprtiche 1 bis 20, 
dadurch gekennzeichnet, 

daB das oder die Identifizierungssignal (e) jeweils in der Be- 
nachrichtigung an den Empfanger (MMS user agent B) durch das 
20 MMS Relay des Service Providers ilber das Vorhandensein eines 
Oder mehrerer neuen Datens^tze einer Multimedia message tiber- 
tragen wird. 

22. Verfahren nach einem der Ansprtiche 1 bis 21, 
25 dadurch gekennzeichnet, 

dafi dem TelekommunikationsgerSt des EmpfSngers eine Wahlein- 
richtung zugeordnet ist, mittels der dieser nach zimindest 
teilweiser Kenntnisnahme des oder der Identifikationssig- 
nal(e) eine BestSLtigung der Empfangsbereitschaft fUr den Da- 
30 tensatz geben kann, und die tJbertragung zum Empfanger erst 
nach Auslosung der Wahleinrichtung ermSglicht ist. 

23. Verfahren nach Anspruch 22, 
dadurch gekennzeichnet, 

35 daB sich die Empfangsbereitschaft nur auf einen Teil der Da- 
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ten bezieht und die Obertragxing nur dieses Teils des Daten- 
satzes freigeschaltet wird. 

24. Verfahren nach einem der Ansprtache 1 bis 23, 
5 dadurch gekennzeichnet, 

daB das oder die zusatzlichen Identif izierungssignal (e) der 
Benachrichtigxing liber bereitstehende Daten (M- 
Notification.ind) xind der eigentlichen Datensendung (M- 
Retrieve.conf ) zugefQgt werden. ^ 

10 

25. Verfahren nach einem der Ansprtiche 1 bis 24, 
dadurch gekennz. eichnet, 

daB die Bereitschaft zum ziimindest teilweisen Empfang der be- 
reitstehenden Daten der vom Empfanger cui den Provider gesand- 
15 ten Nachricht WSP Get.req zugeordnet ist. 

26. Mobiltelekommunikationsgerat (5; 6) zur Durchftthrung des 
Verfahrens nach einem der AnsprUche 1 bis 25, 
dadurch gekennzeichnet, 

20 dafi dem Mobiltelekommunikationsgerat (5; 6) ein Auswahlschal- 
ter (25) zur vdlligen oder teilweisen BestStigving oder Ableh- 
nung der Empfangsbereitschaft ftir einen oder mehrerjB identi- 
fizierten Datensatz oder Datensatze (7) zugeordnet ist. 

25 27. Mobiltelekommunikationsgerat nach Anspruch 26, 
dadurch gekennzeichnet, 
dafi dem Mobiltelekommunikationsgerat (5; 6) ein Anzeigemittel 
(24.) zur optischen oder akustischen Anzeige des oder der I- 
dentifizierungssignale eines oder mehrerer Datensatze (7) zu- 

30 geordnet ist. 

28. Mobiltelekommunikationsgerat nach einem der Anspriiche 26 
Oder 27, 

dadurch gekennzeichnet. 
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dafi der Auswahlschalter (25) softwareseitig implementiert und 
tlber ein Eingabemittel anwahlbar ist. 

29. Mobiltelekommunikationsgerat (5;6), 
5 dadurch gekennzeichnet/ 

daB diesem eine Software zur Belegxing von Header- Feldern 
(17;18;19;20;21/22;23) von Datensendungen mit zumindest einem 
Identifikationssignal zugeordnet ist. 

10 30. Computerprogrammer zeugnis / das ein computerlesbares 

Speichermedivm luafafit, auf dem ein Programm gespeichert ist/ 
das es einem Computer errnQglicht, nachdem es in den Speicher 
des CoDqputers geladen worden ist, innerhalb von Datenlibertra- 
gung in einem Mobilfiuxknetz den zu tlbertragenden Daten zumin- 

15 dest ein Identif izierungssignal mit charakterisierencien Anga- 
ben zu einem Datensatz (7) oder mehreren DatenscLtzen (7) an 
den jeweiligen Empfanger (4) weiterzuleiten. 

31. Conqputeirprogrammer zeugnis nach Anspruch 30, 
20 dadurch geken n z e i c h n e t / 

dafi dieses ein Verfahren nach einem der Ansprtiche 1 bis 25 
bei Datenversand in einem Mobilfunknetz durchftihrt. 

32. Funkkommunikationssystem, bei dem mindestens eine Kompo- 
25 nente nach einem Verfcihren der vorhergehenden Ansprtiche ar- 

beitet . 
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FIG 2 



Name 



Inhalt 



Bemerkungen 



X-Mms-Message-Type 



Siehe Stand derTechnI 



Siehe Stand derTechnIk 



X-Mms-Transaction-ID 



X-Mms-MMS-Vbrsion 



Date 



From 



To 



Cc 



Bcc 



Subject 



X-Mms-Message-Class 



X-Mms-Bqjiry 



X-Mms-Delivery41me 



X-Mms-Priority 



17- 
18- 
19- 
20- 

21- 
22- 

23- 



X-Mms-Content-IO 



Content-IDentifier= 
CI 



Optional: Dieses Feld definiert die 
Lokalisiemng des IVIM-Elements 7 



X-Mms-Content-Type 



Content-type-value= 
CTV 



Optional: Spezifiziert den Inhalts^ des 
MM-Elements 7 



X-Mms-Content-Size 



Content-size-value= 
CSV 



Optional: GesamtgroBe des MM-Elements 
in Octets 



X-Mms-Content-Name 



Content-name=CNV 



Optional: Name des MM-Elemenls 7 



X-Mms-Content-Reiated-URI 



ljocation-value=LV 



Optional: Definiert die Lokalisiemng eines 
anderen MM-Elements, auf das das 
Jeschriebene MM-Element 7 bezogen ist 



X-Mms-Bdemal-Link-Flag 



Extemal-Link-Flag= 
ELF 



Optional: Zeigt an, wenn die MM oder eine seiner 
MM-Elemente einen Link zu einem Element 
auBeriialb der gesamten MM enttiait 



X-Mms-Bdemal-Unk-Size 



Extemal-Link-Size^ 
ELS 



)ptional: GesamtgroBe des g^linkten extemen 
Elements in Octets 
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FIG 3 

172-^X-Mms-Content-ID (0x80): 

CI = Text-string (Textzeichen) 

1 82 ^ X-Mms-Content-Type (0x81 ): 

C7V = stiort-integer (ganze Zahl) 

1 92 ^ X^Mms-Content-Size (0x82): 

CSV = short-Integer (ganze Zahl) 

202 ^ X-Mms-Content-Name (0x83): 

CN = Text-string (Textzeichen) 

21 2 X-Mms-Content-Related-URI (0x84): 
CRV = Text-string (Textzeichen) 

2?? ^ X-Mms-External-Link-Flag (0x85): 
ELF = Yes | No (Ja/Nein) 
Yes= <0ctet128> 
No = <0ctet129> 

232 ^ X-Mms-External-Link-Size(0x86): 

ELS = short-integer (ganze Zahl) 

X-Mms-Status (0x14): 
Status-Value = Expir ed | Retrieved | 
Rejected | Deferred | |Partly-retrleved| 

" Expired = <0ctet128> 
Retrieved = <0ctet129> 
Rejected = <0ctet130> 

Deferred = <Qctet131> 
[^rtly-retrieved = <0ctet132> 
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FIG 4 



20 
21- 

22- 
23 



Name 


Zugew. 
Nummer 


laufende 1 
Nummer 1 


Bemerkung 


Bcc 


0x01 


1 


(Stand derlechnik) 


Cc 


0x02 


2 


X-Mms-Content-Location 


0x03 


3 


Content-Type 


0x04 


4 


Date 


0x05 


5 


X-Mms-Delivery-Report 


UAUU 


u 


X-Mms-Delivery-Time 


0x07 


7 


X-Mnis-Expiry 


UaUO 


a 

u 


From 




q 


X-Mms-Messape-Class 


UaUM 


1 u 


Message-ID 


OxOB 


11 

1 1 


X-Mms-Message-Type 


UAUO 




X-Mms-MMS-Version 


OxOD 


13 


X-Mms-Message-Size 


OxOE 


14 


X-Mms-Priority 


OxOF 


15 


X-Mms-Read-Reply 


0x10 


16 


X-Mms-Report-Allowed 


0x11 


17 


X-Mms-Response-Status 


0x12 


18 


X-Mms-Sender-Visibility 


0x13 


19 


X-Mms-Status 


0x14 


20 


Subject 


0x15 


21 


To 


0x16 


22 


X-Mms-Transaction-id 


0x17 


23 








-X-Mms-Content-ID 


0x80 


27 


Optional: Dieses Feld definiert die Lokalisiemng des MM-Oements 


-X-Mms-Content-Tvoe 


0x81 


28 


Optional: Spezifiziert den Inhaltstyp des MM-Elements 


-X-Mms-Content-Size 


0x82 


29 


Optional: GesamtgroBe des MM-Elements in Octets 


-X-Mms-Content-Name 


0x83 


30 


Optional: Name des MM-Elements in Octets 


X-Mms-Content- 
'Related-URI 


0x84 


31 


Optional: Definiert die Lokalisiemng eines anderen MM-Elements 
auf das das beschriebene MM-Element bezogen ist 


X-Mms-Extemal- 
""Link-Flag 


0x85 


32 


Optional: Zeigt an, wenn die MM oder eine seiner MM-Elemente 
einen Link zu einem Element auBerhalb der gesamten MM enthalt 


-X-Mms-Extemal-Link-Size 


0x86 


33 


Optional: GesamtgroBe des gelinkten extemen Elements In Octets 
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FIG 5 

/ 





Name 


Inhalt 


Bemerkungen 




X-Mms-Mess^e-Type 


gemSB WAP-Standard 


Stand der Technik 




X-Mm^TransacHon-ID 






X4Ams4i/IM&Version 








From 






17- 


X-Mms-Content-ID 


Content-IDentifier= 
CI 


Optional: Dieses Feld definiert die 
Lokalisiemng des MiVI-Elements 


IS- 


X-Mms-Content-Type 


Content-type-value= 
CIV 


Optional: Spezifiziertden Inhaltstyp 
des MM-Elements 


IS- 


X-Mms-Gontent-Size 


Content-size-value=^ 
CSV 


Optional: GesamtgrfiBe des MM-Elements 
in Octets 


20-" 
21- 


y-MmR-nnntpnt-Namp 


nnntpnt-namp — PKR/ 
uujiiclllnlailld — OINV 


OnHnrtQt* Klomo Hoc KAhil Plomanl^ 
UpilUlkll. lAkUHc Uc3 tVIIVlHLieillcniS 


X-Mms-Content-Related4iRI 


LDcation-vaiue=LV 


Optional: Definiert die Lokalisiemng eines 
anderen MlVI-Elements auf das das 
beschriebene MM-Element bezogen ist 


22- 


X-Mms-Extemal-Llnk-Flag 


Ext^l-Unk-Flag^ 
ELF 


Optional: Zeigt an. wenn die MM oder 
eine seiner MM-Elemente einen Link zu 
einem Element auBerhalb der gesamten 
MM enthalt 


23- 


X-Mms-Bdemal-Link-Size 


E(temal-Link-Size= 

as 


Optional: GesanntgrOBe des gelinkten 
extemen Elenfients in Octets 




X-Mms-Message-Class 


gemaB WAP-Standard 


Stand der Technik 




X-Mms-Message-Size 








X-Mms-Expiry 








X-Mms-Content-U)cation 
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FIG 6 MRc 



Name 


Inhalt 


Bemerkungen 


A-MiTis-iViessay6-iype 


iviessaye-iype-vai ue = 
m-retrieve-^onf 


geniaD WAr-oianQaru 


X-Mms-Tiansaction-ID 


Transaction-id-value 




X-Mms-MMS-Veision 


MMS-version-value 




Message-ID 


Message-ID-value 




Date 


Data-value 




From 


From-value 




To 


To-value 




Cc 


Cc-value 




Subject 


Subject-value 




X-Mms-Message-Class 


Message-class-value 




X-Mms-Priority 


Priority-value 




X-Mms-Dellvery-Report 


Deliveiy-report-value 




X-Mms-Read-Reply 


Read-reply-value 




Content-Type 


Content-type-value 





\ 

gemaBWAP-Standard 
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FIG 7 




Name 


Inhalt 


Bemerkungen 


X-Mms-Message-Type 


Message-iype-value= 
m-acknowiedge-ind 


Stand derTechnil( 


X-Mms-Transaction-ID 


Transaction-id-value 


X-Mms-MMS-Version 


MMS-version-value 


X-Mms-Report-Allowed 


report-allowed-value 



gemafiWAP-Standaid 



FIGS 




Nanne 


Inhalt 


Bemerkungen 


X-Mms-Message-Type 


Message-type-value= 
m-delivery-ind 


Stand derTechnik 


X-Mnns-MMS-Verslon 


MMS-versfon-value 




X-Mms-Message-ID 


Message-ID-value 




To 


To-value 




Date 


Date-value 




X-Mms-Status 


Slatus-value 
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pIQ 9 M-Send.req fMMS User Aoent A MMS Relay): 

X-Mms-Message^ype: m-send-req 
X-Mni$4iansaction-ID: TRANSACnON-iO#1 
X-Mms-Verslon: 1.0 
Date: Fri, 14 Jul 2000 14:12:19 +0100 
From: markus.traubefa(5)t-online.de . 
To: andfBas.schmfdt@sal.siemens.de 
To: iQsef.laumen®sal.siemens.de 
Subject: Urlaubsgruesse aus Spiekeroog 
X-Mms-Delivery-Report: Yes 

X-Mms-Confent-ID: <000714.1412.1mafkus.trauberg > 

X-Mms-Content-Name: "Uriaubsgruesse.txt" 

X-Mms-Extemal-Link-flag: Yes 

X-Mms-Extemal-Unk-Size: 8245 

X-Mms-Content-IO: <000714.1412.2marla£.trauberg > 

X-Mms-Conlent-Name: "unser Ferienhausjpg" 

X-Mms-ContenWD: <000714.1412.3irai1ajs.traubefg > 

X-Mms-ConlenWteme: "Spiekeroog.smi" 

X-Mms-Conlent-Related-ID: <000714.1412.2marlcus.trauberg > 

X-Mms-Content-RelatecHD: <000714.1412.4marlajs.trauberg > 

X-Mms-Content4)elated-ID: <000714.1412.5markus.trauberg > 

X-Mms-Content-ID: <000714.1412.4marfcus.trauberg > 

X-Mms-Content-Name: "Meeresratischen .mp3" 

X-Mms-ContenWD: <000714.1412.5markus.trauberg > 

X-Mms-Contenl-Name: "Inselbahn .mpg" 

Content-Type: Applicatlon/Vnd.wap.multiparLrelated 

Start: <000714.1412.3.nfiari(us.trauberg > 

nEntries: 5 

Headei$Len:XX 

DataLemXX 

Content-Type: text'plain; 

X-Mms-Content-ID: <000714,1412.1markiJs.lrauberg > 
Liebe Kollegen, 

SchOne GrOBe aus dem Uriaub. Spiekeroog 1st noal wieder ganz bezaubemd. 

Rdls ihr auf den Geschmack konunt, findet ihr hier mehr Info: httpyAvww^piekeroog.de 

Viel SpaB noch bel der Arbeit ;-) 

MfG 

Mariojs 

HeadersLen: XX ; 
Datalfn: 1265 
Content-Type: image/jpeg 

X-Mms^ontenHD: <000714.1412.2markus.traubetg > 

HeadersLen: XX 
DataljBn:588 

Content-Type: presenlation^descriptiorVsmil, 
X-Mms-Content-ID: <000714.1412.3mai1(us.traubero > 

HeadersLen: XX 
DataLen: 82345 
Content-Type: audiQ/mp3. 

X-Mms-Content-ID: <000714.1412.4markus.trauberg > 

HeadersLen: XX 
DataLen: 632564 
Content-Type: video/mpeg4 

X4/lms-Content-ID: <000714.1412.5nrarkus.trauberg > 
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FIG 10 

M-Send.conf (MMS Relay -» MMS User Aoent A ) : 

X-Mms-Message^Type: m-send-conf 
X-Mms-Transaction-ID: TRANSACTI0N-ID#1 
X-Mms-Version: 1.0 
X-Mms-Message-ID: MESSAGE-ID#1 
X-Mms-Response-Status: ok 
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FIG 11 

M-Notification.ind an einen 'To-Empfanaer": 

X-Mms-Message-Type: m-notification-ind 
X-Mms-Transaction-ID: TRANSACTI0N-ID#2 
X-Mms-Version: 1.0 
From: markus.trauberQ@t-online.de 
X-Mms-Message-Class: Personal 
X-Mms-Message-SIze: XXX (Attachments + Header) 
X-Mms-Explry: 3600 

X-Mms-Content-Location: www.sai.siemens.de/mms-inbox/ABCD.1234 

Subject: Uriaubsgmesse aus Splel(eroog 

X-Mms-Content-ID: <000714.1412.1mari<us.trauberg > 

Content-Type: texl/piain 

X-Mms-Content-Name: "Urlaubsgmesse.txt" 

X-Mms-Content-Size: 212 

X-iVlms-Extemal-Linl(-Flag: Yes 

X-IVIms-Exlernal-Linl<-Size: 8245 

X-iVlms-Content-ID: < 00071 4.1 41 2.2marl(us.trauberg > 

Content-Type: Image/jpeg 

X-I^ms-Content-Name: "unser Ferienhaus.jpg" 

X-Mms-Content-Size: 1265 

X-l\/lms-Content-ID: <000714.1412.3marl(us.trauberg > 
Content-Type: presentationjescription/smii 
X-l\/lms-Content-Name:''Spiel(eroog.smi" 
X-l\/lms-Content-Size: 588 

X-Mms-Content-Related-ID: <000714.1412.2marl<us.trauberg > 
X-Mms-Content-Related-ID: <000714.1412.4marl(us.trauberg > 
X-Mms-Content-Reiated-ID: < 00071 4.1 41 2.5marl(us.trauberg > 
X-IVIms-Content-ID: < 00071 4.1 41 2.4markus.trauberg > 
Content-Type: audlo/mp3 
X-l\/lms-Content-Name: ''i\/Ieeresrauschen .mp3" 
X-Mms-Content-Size: 82345 
X-l\4ms-Content-ID: <000714.1412.5markus.trauberg > 
Content-Type: video/mpeg4 
X-Mms-Content-Name: "Inselbahn .mpg" 
X-i\/lms-Content-Size; 632564 
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FIG 12 

M-Retriev8.conf fMMS Relay MMS User Aoent B): 

X-Mms-Message-Type: m-retrieve-conf 

X-Mms^ransaction-ID: TRANSACnON-ID#3 

X-Mms-Verslon: 1.0 

Dale: FrI, 14 Jul 2000 14:12:19 +0100 

From: mafkus.traub8ro(5)t-online.de 

To: anclreas.schmi(lt(a)sal.sjemens.de 

To: |osef.laumen@sal.siemens.de 

X-Mms-Message-ID: MESSA6E-ID#1 

X-Mms-Delivery-Report: Yes 

Subject: Uriaubsgmesse aus Spiekeroog 

Content-Type: Appllcation/Vnd.wap.mulitpart.related 

Start <000714.1412.3mariais.traub8rg > 

nEntries: 5 

HeadersLen: XX 

DataLen: XX 

Content-Type: text/plain; 

X-Mms-Content-ID: <000714.1412.1markus.trauberg > 
X-Mms-Content-Name: 'Urlaubsgruesse.txt* 
Liebe Kollegen, 

SchOne GruBe aus dem Uriaid). Spiekeroog ist mal wieder ganz bezaubemd. 

Falls ihr auf den Geschmack kommt. findet Ihr hier mehr Info: 
httpy/www.spiekerooQ.de 

Viel SpaB noch bei der Arbeit ;-) 

MfG 

Markus 

HeadersLen: XX 
DataLen: 1265 
Content-Type: lnuige/]peg 
X-Mms-Content-Name: "unser Ferlenhaus.jpg" 
X-Mms-Content-ID: <000714.1412.2markus.trauberg > 

HeadersLen: XX 
DataLen: 588 

Content-Type: presentation_d8scriptlon/smil, 
X-Mms-Content-Name: "Spiekeroog.smi" 
X-Mms-Content-ID: <000714.1412.3markus.trauberg > 

HeadersLen: XX 
DataLen: 82345 
Content-Type: audlo/mp3, 
X-Mms-Content-Name: "Meeresrausctien .mp3" 
X-Mms-Content-ID: <000714.1412.4markus.trauberg > . 

HeadersLen: XX 
DataLen: 632564 
Content-Type: videQ/mpeg4 
X-Mms-Content-Name: "Inseilahn .mpg" 
X-Mms-Content-ID: <000714.1412.5markus.trauberg > 
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FIG 13 

M-Acknowledae.ind (MMS User Aaent B -» MMS Relay) : 

X-Mms-Message-Type: m-acknowledge-ind 
X-Mms-Transactlon-ID:TRANSACTION-ID#3 
X-Mms-Version: 1.0 
X-Mms-Report-Allowed: Yes 



FIG 14 

M-Deliverv.ind (MMS Relay MMS User Aoent A) : 

X-Mms-Message-Type: m-delivery-ind 
X-Mms-Transaction-ID: MESSA6E-ID#1 
X-Mms-Verslon: 1.0 
To: andreas.schmidt@sal.siemens.de 
Date: Fri, 14 Jul 2000 16:45:00 +0100 
X-Mms-Status: Retrieved 
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FIG 15 

M-Retrieve.CQnf (MMS Relay MMS User Aoent B): 

X-Mms-Message-Type: m-retrieve-conf 

X-Mms-Transaction-ID:TRANSACTION-ID#4 

X-Mms-Version: 1.0 

Date: Fri, 14 Jul 2000 14:12:19 +0100 

From: markus.trauberQ@t-online.de 

To: andreas.schmidtOsal. siemens.de 

To: iosef.laumen(g)sal.siemens.de 

X-Mms-Message-ID: MESSAGE-ID#1 

X-Mms-Dellvery-Report: Yes 

Subject: Uriaubsgruesse aus Spiekeroog 

Content-Type: AppIication/vnd.wap.mulitpart.related 

Start: <000714.1412.3markus.trauberg > 

nEntrles: 1 

HeadersLen: XX 

DataLen:XX 

Content-Type: texl/plain; 

X-Mms-Content-ID: <000714.1412.1markus.trauberg > 
X-Mms-Content-Name: "Urlaubsgruesse.txt" 
Liebe Kollegen, 

Schone GruBe aus dem Uriaub. Spiekeroog ist mai wieder ganz 
bezaubernd. 

Falls ihr auf den Geschmack kommt, findet ihr hier mehr Info: 
httD.7/www.SDiekerooQ.de 

Vie! SpaB noch bei der Arbeit ;-) 

MfG 

Markus 
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FIG 16 

M-Acknowledae.ind fMMS User Agent B MMS Relay) : 

X-Mms-Message-Type: m-acknowledge-ind 
X-Mms-Transaction-ID: TRANSACTI0N-ID#4 
X-Mms-Version:1.0 
X-Mms-Report-Allowed: Yes 



FIG 17 

M-Deliverv.ind (MMS Relay -> MMS User Aoent A) : 

X-Mms-Message-Type: m-deliyery-ind 
X-Mms-Transaction-ID: TRANSACTI0N-ID#1 
X-Mms-Version: 1.0 
To: iosef.laumen@sal.siemens.de 
Date: Fri, 14 Jul 2000 15:57:13 +0100 
X-Mms-Status: Partly-retrieyed 
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FIG 18 

X-Mms-Content-ID(0x19) 

X-Mms-Content-ID-value = Text-string | X-Mms-Content-general-form 

X-Mms-Content-general-form = Value-length Text-string 

*(Rarameter) 
(Codierungstypen gemaB [2] und [3]) 



FIG 19 
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FIG 20 
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OxOA 


10 




Message-ID 


OxOB 


11 




X-Mms-Message-Type 


OxOC 


12 


Stand derTechmk 


X-Mms-MMS-Version 


OxOD 


13 


X-^ms-Message-Size 


OxOE 


14 




X-Mms-Priority 


OxOF 


15 




X-Mms-Read-Reply 


OxtO 


16 




X-Mms-Report-Allowed 


0x11 


17 




X-Mrns-Response-Text 


0x12 


18 




X-Mms-Response-Status 


0x13 


19 




X-Mms-Sender-Visibilitv 


0x14 


20 




X-Mms-Status 
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21 




Subject 
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22 




To 


0x17 


23 




X-Mms-Transaction-ld 


0x18 


24 




X-Mms-Content-ID I0x19 


25 


Veranderung durch diese Erfindungsmeldung 



wo 02/058359 



17/21 



PCT/EPOl/14617 



FIG 21 A 


M-Send.req 
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X-Mms-Transaction-ID 
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Date 
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From 
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Subject 
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Message-class-value 
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FIG 21 B 
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X-Mms-Priority 


Priority-value 
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Content 
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Version number 


From 


Sender address 


X-Mms-ContenHD 


Inhalts-ldentiffkator 
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X-Mms-Message-Class 


Message-class-value 
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X-Mms-Content-Location 


Content-location-wlue 
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FIG 23 

M-SreofM-UAA-^ M-SR): 

X-Mms-Message-Type: m-send-req 

X-Mms-TransacBon-ID: 7RANSACTI0N-ID#1 

X-Mms-Version:1.0 

Date: Fri, 14 Jul 2000 14:12:19 +0100 

From: marfajs.trauberoOt'Online.de 

To: andfBas.schmidt®sal.siemens.de 

Subject: Uriaubsgmesse aus Spiekeroog 

X-Mms-Delivery-Report: Yes ^ 

X-Mms-Content-ID: <000714.1412.1markus.trauberg >; Name = 

"Urlaubsgruesse-bd"; Extemal-Unk-Flag = Yes; 

Extemal-Unk-Size = 8245 
X-Mms-Content-ID: <000714.1412.2mafkus.traubefg >; Name = "unserFei1enhaus.jpg' 
X-Mms-Content-ID: <000714.1412.3markus.trauberg >; Name = SpiekBroog-smi"; RelatecHD = 

<000714.1412.2markus.trauberg >; Related-ID = 

<000714.1412.4mariajs.lrauberg >; Related-ID = 

<000714.1412.5rrarkus.trauberg > 
X-Mms-Content-ID: <000714.1412.4nnarkus,trauberg >; Name = "Meeresrauschen .mp3" 
X-Mms-Content-ID : <000714.1412.5TOrkus.trauberg >; Name = "Inselbahn .mpj 

Content-Type: Application/vnd.wap.multiparLiBlated: Start ^ <000714.1412.3mari(us.traubefg > 
nEntries: 5 
HeadersLen: XX 
DataLenrXX 

Content-Type: text/plain; 

|X-Mms-Content-ID: <000714.1412.1markus.trauberg > | 
UebeKollegen, 

Schfine GrOBe aus dem Uriaub. Spiekeroog ist mal wieder ganz bezaubemd. 

Falls ihr auf den Geschmack kommt. findet ihr hier mehr Info: httDVAvww.SDiekerQOQ.de 

Viel SpaB noch bei der Arbeit 

MiG 

Markus 

HeadersLen: XX 
DataLen: 1265 

Content-Type: image/lpeg 



1 X-Mms-Content-ID: <000714.1412.2maricus.trauberg > 


1 


HeadersLen: XX 




DataLen: 588 




Content-Type: application/smll, 




|X-Mms-Content-ID: <0007l4.1412.3mari(us.trauberg > 


1 


HeadersLen: XX 




DataLen: 82345 




Content-Type: audiQ/mp3, 




|X-Mms-ContBnt-ID: <000714.1412.4markus.trauberg > | 


HeadersLen: XX 




DataLen: 632564 




Content-Type: video/mpeg4 




|X-Mnns-ContenHD: <000714.1412.5mariajs.trauberg > | 
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FIG 24 

M-Nind an einen 'To-Empfanaer": 

X-Mms-Message-Type: m-notification-ind 
X-Mms-Transaction-ID: TRANSACTI0N-ID#2 . 
X-Mms-Version: 1.0 
.. From: markus.trauberQ(Q)t-online.de .. . 

X-Mms-Message-Class: Personal 
X-Mms-Message-Size: XXX (Attachments + "Header) 
X-Mms-Expiry: 3600 

X-Mms-Content-Location: www.sal.siemens.de/mns-inbox/ABCD.1234 

Subject: Uriaubsgruesse aus Spiekeroog 



X-Mms-Content-ID:<000714.1412.1marl(us.trauberg >;Type = 
text/plain; Name = "Urlaubsgmesse.b(t"; Size = 212; 
External-Link: Yes; External-Link-Size = 8245 
X-Mms-Content-ID:<000714.1412.2markus.trauberg >;Type = 
image/bmp; Name = "unser Ferienhaus.bmp"; Size = 
5863; Original-Type = image/jpeg; Original-Size = 1265 
X-Mms-Content-ID:<000714.1412.3markus.trauberg >; Type = 
application/smil; Name = Spiekeroog.smi"; 
Content-Size = 588; Related-ID = 
<000714.1412.2markus.trauberg >; Related-iD = 
<000714.1412.4markus.trauberg >; Related-ID = 
<000714.1412.5markus.trauberg > 
X-Mms-Content-ID:< 00071 4.1 41 2.4markus.trauberg >;Type = 
audio/mp3 ; Name = "Meeresrauschen .mp3"; 
Size = 82345 

X-Mms-Content-ID :<000714.1412.5markus.trauberg >; Type = 

video/mpeg4; Name = "Inselbahn .mpg" ; Size = 632564 
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FIG 25 

M-RcQnf(M-SP-^M - UAB): 

X-Mms-Message-Type: m-fetrieve-conf 
X-Mms-Transaction-ID: TRANSACnON-ID#3 
X-Mms-Version:1.0 
Date: Fri. 14 Jul 2000 14:12:19 +0100 
From: markus.traubera(Q)t-online.de 
To: andreas.schmidt@sal.siemens.de 
X-Mms-Message-ID: MESSAGE-ID#1 
Subject Urlaubsgruesse aus Spiekeroog 
X-l\^ms-Delivery-Report Yes 

Content-Type: Applicatlon/Vnd.wap.multipart.r6iated; Start = <000714.1412.3.inariajs.trauberg > 

nEntries: 5 
HeadersLen: XX 
Dataijen:XX 

Content-Type: text/plain; 

I X-Mms-Content-ID: <000714.1412.1mafkus.traubefg >; Name = "Urlaubsgruesse.txT | 
Liebe Kollegen, 

Schdne GruBe aus dem Uriaub. Spielceroog ist mal wieder ganz bezaubemd. 

Falls ihr auf den Geschmack kommt findet ihr hier mehr Info: httD:/Aww.sDiekerooo.de 

Viel SpaB noch be! der Arbeit 

m 

Marlais 

HeadersLen: XX 
DataLen: 5863 

Content-Type: image/bmp 

X-Mms-Content-ID: <000714.1412.2n)arkus.trauberg >; Name = 

"unser Ferienhaus.bmp"; Original-Type = image/ipeg; 
Original-Size = 1265 

HeadersLen: XX 
DataLen: 588 

Content-Type: application/smii, 

i X-Mms-Content-ID: <00Q714.1412.3marlais.trauberg >; Name = Splekeroog.smi" | 

HeadersLen: XX 
Datal£n: 82345 

Content-Type: audio/mpS. 

X-Mms^ontent-ID: <00Q714.1412.4maf)ajs.trauberg >; Name = "Meeresrauschen ■mp3''| 

HeadersLen: XX 
DataLen: 632564 

Content-Type: video/mpeg4. 

I X-Mms-Content-ID: <000714.1412.5marlajs.trauberg >; Name = "Inselbahn .mpg" I 
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